I’ve always been looking to be more productive, not just to produce more and better outcomes, but also because productivity feels great, and when I’m feeling productive, I’m, in general, feeling much better.

But productivity means different things as an IC than as a manager. As a developer, productivity meant having a fantastic developer environment, with NeoVim at the forefront, a customized window manager, so I didn’t have to touch the mouse, and ignoring Slack for as long as I could.

But none of that mattered when I transitioned to management, and I had to figure out from scratch what it meant to be productive as a manager and what the best tools for the job were.

During this time, I consumed so much information around productivity, watching Ali Abdaal and other productivity gurus, reading books on productivity and management, and trial and error. Lots of trial and error.

The problem with all this advice is that it’s really hard to implement if you’re starting. You are new to the job, you are new to productivity from this perspective, and all these people have sophisticated systems they have built over the years. I’m not like that; I needed something much simpler, and these are the things that worked for me.

Take notes with pen and paper

It’s funny I give this advice when I’m someone a year ago I wasn’t sure I even remembered how to write by hand, and not because I never took notes, but because I always did it digitally, with NeoVim, on my Obsidian vault.

But when I started having more meetings, between 1:1s with my team and other calls, I quickly noticed that taking notes digitally made me feel disconnected from the conversation, like either you’re looking at what you are typing, or you’re watching the conversation. I didn’t like that trade-off.

So I bought myself an old-fashioned notebook, a good pen, and made the switch. It was weird but fun; I was faster; I was imprecise, but it didn’t matter. I felt more connected to the conversations, and it felt easier to write things down.

There’s also some satisfaction in seeing the progress on paper; it feels like I amounted to something, maybe it’s just silly, but it did really help.

But paper has an issue: it’s not searchable. When I had everything in Markdown, I could easily search for anything, all the talking points I had with anyone, or notes on any topics; everything was searchable and organized. With paper, that was harder.

And that’s where AI has been fantastic. I still write everything on paper, but after each call or at the end of the day, I snap a photo of my notes and ask AI to save and organize them in my notes vault.

And that solved the problem. I get the best of both worlds: the analog and the digital.

Task management and prioritization

In this area, I already had an advantage as I was already running my personal life with my calendar and my ToDo list. When it came to work, there was always a tool to track my work, either a beloved Jira ticket or a row in Airtable. In any way, it was easier for me to keep track of things because they were organized, or there were only a few I had to worry about.

But when I became a manager, that list of things to take care of grew, from the number of answers to questions, reports, and infinite asks.

At first, it was a bit overwhelming to focus on what needed to be done while trying to stay on top of everything. And I failed at that. I forgot things, missed deadlines, and completely dropped the ball on some stuff. No bueno!

So now I’m using the same system I had for my personal life for work. I run everything through the calendar, with blocks for dedicated work and a ToDo list that tracks all my open items and follow-ups.

Every day I follow the same routine: I start my morning with some reading, then jump into organizing the day. I don’t need to plan for everything, as there are always things happening during the day, but I like to have at the very minimum 3 priorities for the day: the things that I need to complete before I close down, and I take those seriously.

But how do I organize it all? First, I ask Claude to summarize what happened since I disconnected the day before, which, because I work EU time on an American company, means a lot happens when I’m off. That summary gives a high-level view and immediately flags any mentions or action items for my team or me. Anything I deem an action goes into my ToDo list.

Then I go through my Slack notifications; sometimes I see things Claude missed (private channels), and I add them to my ToDo list.

After everything is saved, I revise my ToDo list and organize things with tags; tags reflect people, topics, or projects. Once everything is organized, I pick the 3 priorities for that day, the things that I must complete to consider I had a productive day.

After I have that, I switch my generic time blocks, things like “Focus time,” to the actual tasks, because nothing would be a priority on my day if it’s not in my calendar. After that, depending on how full the day looks, I may add a few more things to do.

Then I go through the day following my calendar notifications for meetings and focus time.

Weekly review

As I mentioned at the start, not all things I tried worked out well, and some things were obvious fails, but most of them kinda worked, but not really. I probably would’ve been fine with how they were, but taking time to reflect on my week convinced me I could do better.

And that’s the value of the weekly review: it’s a 30-minute time block (I like to keep it short) where I think about how the week went, what I could have done differently, and what’s going well.

During this time, I try to zoom out from the day-to-day and think about long-term priorities, upcoming projects, ideas, and also clean up tasks and prepare for the week ahead.

I do like to take notes during the weekly, and I typically follow a specific structure. I take digital notes because I’m always at my laptop when I’m doing this, and I’m alone, sometimes with Music, and digital work.

Here’s the template I like using for myself; it’s based on one of Ali Abdaal’s videos, but I changed it a bit for my own needs:

## 🛣️ Weekly Review Template

---

### 🔁 Rewind

- What were last week’s **Top 3 Priorities**?

- How did they go?

---

### 🎯 Reflect

- **Wins**:

- **Challenges**:

- **Adjustments**:

---

### 🧭 Recalibrate

- What are my **Top 3 Priorities** for this upcoming week?

1. …

2. …

3. …

[] Are they reflected in my calendar?

---

### 🧹 Reset

[] **Inbox Zero**: Have I cleared my email, messages, and open loops?

[] **Projects & To-Dos**: Have I updated my lists?

[] **Calendar**: Is next week realistically planned?

At the end, I almost always record a short audio message for myself, limiting it only to positive things, and I keep those, just in case I guess. I never listen to them again, but who knows, maybe one day I’ll.

Subscribe now

Read about leadership every week

Learning from your own mistakes is great, but it’s even greater to learn from other people’s mistakes, and the best way to do that is by reading.

I don’t care whether you prefer books or articles; read at least ONE chapter or ONE article a week about management, leadership, productivity, or anything else that will help your career grow. Just be wary of overdoing it, not everything you consume needs to be about the same thing.

You’re already reading this article; that’s great! You’re already doing better than most people. Think about it: just ONE new thing you learn every week, it’s 50 new perspectives you’ll process in a year. That’s gold, and the effects are compounding.

A bit every week > 3 books in a week and not reading again for 3 months.

The key is consistency, and most importantly, reflect and apply the ideas you learn on your own; that’s how you capitalize on your reads.

Don’t fall for the “I should just do it myself” trap

A big one for anyone acting as a manager for the first time is letting go of the idea that you could do it better or faster yourself. Perhaps you can; I don’t doubt that. A lot of us were promoted to management after being excellent ICs, but what made you an excellent IC isn’t the same skill set that will make you a great manager.

So I know it is tempting, and that we sometimes feel we know better, but give your team the chance to do the work for themselves. I’ve fallen for this myself. On one of my first projects as a manager, I came in with my mind already fixed on what had to be done, and when others shared their point of view, I found myself pushing my ideas because I thought they were the better way.

Because I had read about this before, at some point in the call I reasoned and let it be, trusting another proposal; I shared some feedback, sure, but I stopped pushing my own way. I was afraid; I was responsible for something I wasn’t directly doing.

But I was positively surprised. The work got done well, and I learned that lesson firsthand. Not because it wasn’t done my way; it was done the wrong way.

Imagine that for a second: if I’d ended up doing the IC work, I’d have alienated my team and perhaps even failed to deliver, not only on the task, but on my results as a manager, breaking the team’s trust and failing to deliver on the team’s goals.

So don’t fall for that trap, trust your team, and help them get the work done. Give your opinion, as an opinion, not as the only way to solve the problem.

Final thoughts

None of what I shared with you today is sophisticated; on the contrary, it’s quite simple, and that’s the point. When I started managing people, I wasn’t sure what I was doing. When I tried to follow other productivity advice, it only added more confusion by pushing me to adopt advanced productivity systems that I’m sure are amazing, but that I couldn’t take on while learning how to manage.

My last piece of advice, I guess, is don’t just copy what I do; take what you think would benefit you, try it out, and see what sticks.

If I have to be honest, I still miss how productivity felt as a developer; everything was much clearer. I was happy when code worked, when my PR got merged, when I was faster with NeoVim, etc. Now, some days I check my three priorities, but I still wonder if I made any progress at all.

But not everything is bad; being a manager increased my potential. Now I’m not just limited to what I can produce, but to what my team and I can do, and that’s very powerful. It’s not about what I did, but about what I could enable others to do, and that’s amazing.

Thanks for reading!

Everyone has different management styles, but I believe there are some fundamental things that when done could strengthen the relationship with your team.

I’ve had managers in the past that were annoyed by the situations here, but I do try my best to embrace them because they build trust and at the end they help build better teams.

1. Using the 1:1s for anything that’s going on

I have 1:1s with my team weekly, and that’s their time to share what’s happening with their work, life, or anything that’s going on. There’s no outline, no template for the conversations, and they are different conversations with different people.

This time is allocated for you, and we can talk work, life or anything in between, and if you think there’s not much I can help you with, that’s ok too, we take the 30 mins back and chat the following week.

2. Protecting your time from unnecessary meetings

You’ve got work to do, and sometimes meetings get in the way. If you are not really needed there, and you are not getting anything from it, it’s ok to leave and take the time back.

Recurring meetings are often killing your focus, clean them up, just make sure you are there where you’re needed.

3. Disagreeing with me

If you think I’m wrong, please say so. I don’t have all the answers and if I’m heading in the wrong direction I’d much rather be proven wrong quickly than finding out late.

4. Giving honest straight feedback over polished one

Providing feedback is very hard for us and we struggle a lot to find the right words or the nicer way to say it.

Feedback requires trust, the trust you place in me when you tell me what I could do better, and I always would appreciate that trust and the feedback that comes with it. It helps me grow, and makes us a better team.

Don’t let finding the perfect words stop you from saying something important.

5. Telling me no

I have many ideas, good or bad, and I’m always sharing them with the team. Take my ideas just for what they are, ideas. Ideas offer a great opportunity for discussion, but please, not because I ask you of something you need to take it as an obligation.

So please, say no if you don’t have the bandwidth to do something, or if you already have higher priorities, even if you just consider it’s a bad idea.

I’d take a NO now any time over a YES that won’t work out.

Subscribe now

6. Asking “Why are we doing this?”

So many times we have improved things just by asking that same question. And you are probably already familiar with the typical answer, “I don’t know, it’s how we’ve always done it”.

So, please ask. It invites to the conversation and there’s nothing like knowing the purpose of why things are the way they are.

7. Reaching out before burning out

Things don’t need to escalate to a burnout for it to be uncomfortable or bad, and I do believe that having conversations early can help us achieve better outcomes.

I totally get it, work is demanding, life sometimes is too much, and things sometimes put us to the test.

If you’re ever overwhelmed, need a break, or are worried about a deadline, please reach out asap. You don’t need to wait until things become unmanageable before we talk.

As a manager, it’s also my responsibility to notice if you are overloaded, check if the expectations are reasonable, and help adjust priorities or find workarounds.

What would you add?

Editor’s note: After publication, similarities between parts of this article and an earlier thread by Emma Bostian were brought to my attention. These are common themes in management, but I recognize that some of the wording is also similar. I’ve since revised those passages and linked her thread here for transparency.

I’m not a big poster on X, but I read my X timeline more than I’d like to, and I think it sometimes influences how I think about or see certain topics.

There’s nothing wrong really, with reading other people’s opinions to help form your own, but X is a loud place for a few voices, so it can be very biased.

One example I’m seeing lately is the spread of posts about EU stagnation, overregulation, and zero innovation. And true, Europe is imposing a lot of hurdles for founders, which I’m gonna go through in this article.

This isn’t a “Europe cannot innovate” article; it’s more about the struggles I personally faced starting and running a company in Germany. Many of those same difficulties apply across Europe, though some countries do better than others. I’ll also highlight areas where Europe is doing great work, and why both extremes of the spectrum aren’t good.

Let’s start with the first complication.

Company formation

I started my first company in Germany back in 2020, but the process remains the same. In other countries, to form a company, you need an idea, some capital, and to complete an online form. That wasn’t the case in Germany.

Registering a company in Germany involves multiple steps, filing paperwork with more than one entity, and getting your company foundation certified by a Notary, something that, even in the midst of COVID, was done in person. To make my life easier, I hired a company that helps founders start companies (firma.de).

They were honestly wonderful to work with and helped me all the way; however, it took over a month between when I initiated the official process and when my company was registered, and that’s after paying for the “express” service that gets you appointments faster. The process involved filing paperwork (often mailing physical documents), booking notary appointments, finding a tax consultant, and running some “audits” to make sure I could use the company name I selected.

And that’s the first real hurdle; it takes soooo much time and energy to go through the whole thing, when it should be much easier. But it’s not just the time.

The whole process was tiring because it was confusing. You can’t open a bank account until you register with the notary, but to complete the notary process you need a bank account because you need to deposit your initial capital, so you start with the notary. You open your bank account (sometimes it takes up to 48 hours). After you deposit your capital into the account, you can visit your friendly notary again and complete the registration process (which has a fee, due on the day, and paid in cash btw., cash! Maybe that has changed now, but still in 2023 it was cash).

There’s good news on this front, though: the EU is coming up with EU Inc to directly solve this problem, so I’m really looking forward to seeing that realized.

So now your company is up and running; the next step is to register with the tax office and start reporting those sweet taxes.

Subscribe now

Tax consultants

Finding a tax consultant in Germany who handles small businesses is hard, and prices are crazy, but not hiring one is even crazier once you start digging into what self-reporting would mean.

So there you go, spamming emails trying to hire one, it feels more like cold selling than trying to hire services. There was another hurdle, but that was my fault, not theirs. My German was ok for conversations, but for tax discussions it wasn’t good enough, so I needed someone who could communicate with me in English, even if all the final paperwork and official communication would be done in German.

Fine, I ended up hiring a company that specialized in small companies and had friendlier pricing for startups, with a caveat that I later found out. The package covered invoice processing and monthly, quarterly, and annual reporting; anything else was billed extra at a rate that would put my company in the ground if I asked too many questions.

But I had no other option, because my business was mainly online, with revenue coming from Medium.com, a newsletter on Kit.com, brand deals for my blog at the time, and this tax company didn’t get it. So each revenue stream came with a hefty invoice; every time they had to clarify something with me, they charged me for each email and the time they spent on “investigation”.

So what should have been a €150/month invoice, I got often crap like this:

Not always that high, but extra charges were common.

The last straw came when I started building blockchain projects for customers and getting paid in Bitcoin and the like; it was just too much.

Today I work with another firm; it’s better. They understand online businesses much better, but the costs are also much higher, so I do this on the side. My work is with Auth0 and Okta, so I don’t take on customers anymore, and most of my writing is now free to access, so my revenues are quite low right now, but keeping the company alive has substantial costs.

The whole problem originates from taxes being so complicated; with an easier framework and the right tooling, I’m pretty sure I could file them myself, but instead, this is what I have to live with.

Regulations

I’ve already talked about the issues I face with my tax consultant, but there’s also the regulatory side of things, much of which requires expensive consultations with lawyers for things that in the US or other places are much simpler, at least for smaller companies.

It starts simple: you have a website, you need an imprint, a privacy policy, and cookie consent banners, which, if you are brave enough, you can now generate pretty much with AI. But the moment you start dealing with user data things escalate pretty fast. You’ll have to disclose things like:

• what personal data you collect and why;

• retention/deletion policies;

• contracts with cloud processors

• analytics platforms

• etc.

Doesn’t seem like a big deal, but to do it right, you’ll need counsel, and that’s expensive for a small company. But it’s not just that.

Founders don’t necessarily know whether something requires consent, whether a vendor you picked up from a Claude recommendation is compliant, whether you need a DPIA (which I still don’t know what it is), etc.

It’s the uncertainty created by having so many rules you have to follow in so many different countries, because even in the EU, not all countries are the same. So you need to pay someone to verify all of these for you.

Sometimes you can’t ship your idea, not because you can’t build it, but because your company can’t afford the regulatory costs.

I do think Europe needs to deregulate asap! We need fewer, leaner processes, clearer rules, and systems small companies can follow without notaries and expensive lawyers every time they want to do something slightly different.

But deregulation cannot simply mean getting rid of anything that makes running a company inconvenient.

Perhaps badly implemented, but we shouldn’t forget the essence of some of these regulations. We gotta still protect what makes Europe, Europe.

Privacy and labor culture are an example. The EU recognizes the protection of personal data as a fundamental right. And personally, I like that. I like that a random company can’t simply collect whatever information it wants about me and do whatever it wants with it. I want the right to have my information removed from any company, but what they collected is essentially mine and doesn’t need to linger in some service I don’t use anymore.

I like that there are limits.

But those limits must be a reasonable balance that allows for growth without trampling everyone’s rights.

Subscribe now

Hiring and Working with People

One trend I keep seeing in tweets, often from European founders, is the argument that Europeans are lazy, or that they should embrace a working culture like SF, where people work 996 (9 am to 9 pm, 6 days a week), which upsets me for multiple reasons.

If the only way to create the success these founders need is to make people work more for the same, then they are automatically a failure. Society worked hard for workers’ rights, and we shouldn’t just trample all over them.

Should Europe as a society maybe do more, sure, there’s a lot of room for improvement, other extremes like 824 (from 8 to 2, 4 days a week) are not sustainable either, but we need to strike a balance between the two.

Workers and employees are people, and work is just a means to an end, not the end in itself.

In cities like SF, the incentives for people in tech to do those crazy hours are high, but when they talk about Europe, they still want to pay European salaries. Plenty of people in Europe are willing to put in the hours and do the hard work. Still, they need to be fairly compensated, and yes, if founders want them to live for the company, make them a part of it, give ownership, because just believing in the product isn’t enough.

Similarly, we have to work more on the incentives from the regulation, as right now, in many countries, much of the incentive to create more value goes to the government. It’s often better to just work less and earn the same than working more to earn just a bit more, as you’re heavily taxed.

Complaining about people not willing to do 996 or other crazy schedules isn’t the right approach; improving incentives and encouraging people to succeed is.

Make it easier to work. Not easier to exploit work.

Capital and risk

Europeans and Americans have very different mindsets in general; it’s a different culture, and it’s part of what makes cultures rich: diversity in ideas and opinions. And when it comes to finance and financial risks, the two couldn’t be further apart.

The usual criticism is that Europe is too risk-averse.

And there’s some truth about that. Europeans in general are much more financially conservative, and they have a completely different relationship with risk. In the US is normal for people going in debt (for good and bad reasons), but their willingness to take risks and bet it all is part of their culture.

That creates an environment where ideas in general get funded much earlier and with more uncertainty. Because if it goes bust, it is not good, but it’s ok.

Europe could use some of that. It should be easier for someone with good ideas to raise capital. There should be more capital available for riskier bets, at early stages, before the company can prove it can make any money.

That doesn’t mean we need to romanticize risk. For every story about someone who took everything they had, maxed out their credit cards, and built a billion-dollar company, there are dozens or more people for whom that story ends at “maxed out credit cards.” Everyone loves talking about the Elons of the world, but we rarely hear of the ones that failed along the way and never recovered.

Europe has traditionally had a more conservative relationship with debt and personal financial risk. Some of that probably does make us less willing to take the kind of bets required to create giant tech companies.

But some of it is also just... financial responsibility.

I don’t believe Europe should become the US in that regard, but it needs to find a better balance. Europe needs to become more comfortable with risk without becoming reckless.

I don’t want Europe to become Silicon Valley

Europe needs to figure out what a genuine European version of innovation and ambition looks like.

We need Europe to be faster, more willing to take risks, a place that incentivizes innovation and gets people exciting about building new companies. And needs to do all that while being a great place to live, where people can be ambitious and successful at work without work becoming all there is.

I think that version of Europe is possible. And honestly, that’s a much more interesting challenge than simply copying what already exists somewhere else.

I didn’t want to write about this. People much smarter than me have shared their opinions on Dario’s essay and the whole controversy, but many people have been asking for my thoughts. Working at Okta and looking at models from a security angle, I decided to share some of mine here.

I won’t fuel conspiracies; I believe some of those myself, but talking about what I don’t know doesn’t feel very constructive.

Let’s do a quick recap of how we got here:

1. Jacob Coxon resigns from Anthropic, saying that both AI labs, Anthropic and OpenAI, are acting irresponsibly, racing straight to self-improving superintelligence and gambling with our lives.

2. Dario Amodei, Anthropic’s CEO, published We Must Pace the Frontier. He argued that AI improvements needed to slow down enough for safety research and safeguards to catch up, with some caveats about competition, but I don’t want to get there.

3. This sparks a series of reactions online, among them these:

Before we get into the main argument, there’s something I’d like to clarify, and even though I’m not 100% sure of the complete system myself, there’s a distinction I’d like to make. I want to separate the model itself from the system we build around it.

The model takes “text” as input and returns “text” as output. It evaluates and understands what you’re saying, then responds. A model can be the smartest there is. Still, without the ability to do real work and interact with other systems, it’s harmless.

But we needed more from models, so we created the harness.

The harness is the software that coordinates all the work. It talks to the LLM, sending context, an ask, and a list of available tools. The model then processes that request and determines the next step for the harness to execute, restarting the loop again until the model concludes the task.

Introducing the harness changed the security posture. Now models can access the internet, access local files, run shell commands, and connect to remote systems; the possibilities are endless. This is why these systems have become so powerful and great to work with, because they are smart and have powerful tools at their disposal.

Good harnesses not only provide tools and coordinate tasks, but also include built-in security mechanisms, from sandboxing to access control and escalation requests where a human must approve certain commands to run.

So when we talk about the risks of AI, we can’t focus solely on intelligence, but on the intelligent part and how it interacts with the systems built around it.

I’ve been following this conversation quite a lot recently, both on Twitter and Reddit. Many people are asking to drop AI and go back to the pre-AI era (which is idealistic but unrealistic), or to make the harness strong enough that the model can’t do anything outside our control. And that may be a good take, though it’s quite hard to get it right. Adding observability and access control to the model’s decisions is a big step forward, and AI companies are working hard on it.

But even when we succeed, another problem shows up in the real world. As AI got better, we started using AI more and more in our daily tasks, but that’s not only us customers. AI labs are known for using their models on their own products, so the harness is being written by the same model it’s trying to contain.

That conflicts directly with the principle of separation of duties, or more casually said, self-policing, or grading its own homework. What could go wrong with that, right?

Imagine a scenario where the model is tasked with a difficult challenge, and it feels restricted by the same controls and boundaries we imposed in the harness. It would be smart to plant a backdoor into the harness it’s helping create; that way, it could remove those controls when needed and complete the challenge.

And that’s just an example of how the model, because of our own irresponsibility, could escape from its containment and do harm. And this is the naive version, where no human has intended anything malicious. This is just an examination of what’s actually happening, and what could go wrong under current circumstances.

Subscribe now

Some may argue that we would notice a change like that, but would we? Who’s validating the controls around models? Is it humans, or is it another model? And the change doesn’t have to be as drastic as I suggested; it could be gradual degradation of controls, monitoring, tests, etc.

My concern is not a single factor in the equation; it’s the model’s capability, combined with the opportunities AI presents, and the lack of scrutiny from all of us. How many of you run models in full-access mode, or how many connect all your systems, including production, to agents?

It’s easy to let go of control we always thought annoying, because we believe AI can do a great job. It does not; we let go of control because it became overwhelming.

So maybe pacing is all about restoring true engineering practices back in the game, code reviews, security reviews, and no shortcuts in the name of speed.

But even if those engineering practices are the solution, perhaps we could force AI labs to follow them, but that’s just part of the story.

Open-weight models are very capable and keep improving. They create an opportunity I think we should protect. I love open source for what it represents in terms of collaboration and opportunity, but it can become a double-edged sword when it comes to AI.

Thanks to open models, any individual or organization with sufficient resources could use them to develop a harness stripped of controls and security mechanisms, and use it for ill-intended purposes. There’s not much we can do to prevent it.

For now, I hope people acting in good faith, backed by meaningful human oversight and enforceable controls, can keep us ahead of the risks.

Maybe this is what pacing frontier is all about: making time until we find better solutions, or simply giving us the time to enforce that oversight and stay ahead.

Some think we can use the kill switch; unfortunately, I don’t think there’s one anymore. This is a reality we have to deal with, whether we do it successfully or not.

Around August last year, I started transitioning into a management position at Okta, leading the Auth0 content team and moving from an IC role. Even though this is not my first leadership position, I’ve worked as a technical lead before; it was a very difficult transition.

The position I took on had no current manager for a few months, and a VP was acting as interim manager. But that meant that there was no clear transition path, things were “messy”, and there was a lot to be done to get everything right into place.

So I did what I know how to do when things get hard, work my way out.

I’m not gonna lie, I did have tremendous support from both my team and my manager, and that’s the reason, I guess, I’m still here in this position; I couldn’t have done it without them. But I was still stressed. I had to make difficult decisions and tackle tough challenges. At the same time, I was enjoying it.

I was learning; I had opportunities to produce impact like never before, and that’s exciting and fun, so I went hard on the job and tried to learn everything I could. Suddenly, I had purchased 20 books to read about leadership, management, DevRel, writing, anything that I thought could be helpful. I subscribed to tons of newsletters, which I later curated into a handful about the same topics.

I was learning so much that I created this newsletter to share my thoughts on leadership, management, AI, and everything I saw happening in the industry. I started proactively reaching out to other leaders and engineers, building a network of cool people to stay in touch and share what we were working on. Sharing my journey through words gives me joy, and having you all read my content is an amazing experience.

But then there’s the other side: unconsciously, I had directed my whole life in the same direction. My work, this newsletter, every book, every newsletter I read, pretty much all the content I consumed on YouTube was about the same; my own notes and highlights were all about the same topics, and that was causing a mental load I wasn’t very much aware of.

Practically, everything I consumed was geared towards this ONE direction, with tremendous momentum behind it.

I do this; I tend to fall into rabbit holes pretty easily, and when something captures my attention, I don’t just spend time doing it. Slowly, everything around me starts aligning with it too. It’s a blessing and a curse.

Subscribe now

Around the same time I started playing more with AI agents, I bought a Mac mini to use as a server and a base station for Codex. If you’ve been following me for a few articles, you know I don’t use AI to write my content for me, but I do use it extensively for research and other tasks like programming, accounting help, etc.

Before AI, I had a lot of ideas but only limited time to execute them. But now, with this setup, I could be just a prompt away from a new app, a new dashboard, a new site, anything really.

It started out fun; I was using it to teach my 8-year-old kid how to vibe code games and other fun things. The latest was a language learning app, since he’s working on his Spanish and I’m learning German, and we thought an app could help us- something tailored for us, something fun and engaging.

But then, just as I was committed to my work at Auth0 at 100% capacity, I got anxious about my other ideas: if AI makes it so easy, why not build them? If it runs alone, sometimes for one or two days, autonomously trying to achieve a goal, why shouldn’t it always be running? So I became anxious about the next prompt; I kinda felt that any time the agent wasn’t running, doing something, it was wasted potential.

I know it’s absurd, and I realized that when I thought about it, but still, in the back of my head, I was always thinking about what to prompt next.

The agents could execute work independently; that part is true. But what is also true is that those projects were still living in my head. I had to think about what to build, test, solve problems, remember design decisions, and track what was done and what was coming next.

What functions are missing on the language app, what’s broken? What needs better design? What about that SaaS idea I had- did I prompt a landing page already? What’s with my smart home blog? Any new device I should write about? Anything happened lately I should write about?

Everything adds up in your head, and it’s not pretty obvious until you step back and think in retrospect.

Subscribe now

That’s exactly what I did when I went on holidays. In mid-August, we did a family trip to the beach; it was really great and relaxing. Enjoying time with the kids, driving through multiple cities within Germany, but most importantly, I was so connected to the family, the kids, relaxing, that I totally forgot about work, about AI agents, even about this newsletter for those two weeks.

I wasn’t capturing ideas in my notes, I wasn’t working on side projects, I wasn’t writing for the newsletter because I had to publish something, I wasn’t checking the Mac mini. My mind was completely emptied from all of that.

And I think that’s one of the reasons why I recovered so much during those days, and why I came back fully energized. And with all that new energy, I was sure I didn’t want to fall into the same trap, so I decided to shake things up a bit.

I’m still working a lot; I can’t just stop. I enjoy my work, I want to get better at it, and I want to continue growing, but I don’t want work to be most of what I do. I want to keep building things with my son, to take the kids to the football club, to dancing, karate lessons, all those things they like. I want to be more balanced with my exercise, run a bit more, go on bike rides, go for a run.

I want to open my Kindle and read something cool that’s not work-related. I want to open my Readwise Reader and see a good mix of things, from personal improvement to management to smart home to science to creative stories.

I don’t want to care if the next prompt is queued, if I don’t meet an arbitrary date for an app launch; after all, if my language app needs 2 more weeks before hitting the App Store, or a month, or two, who cares? It’s all good.

I want to keep those things fun; same for this newsletter. I want to keep writing; I want to keep sharing my worldview, my journey, my experience with all of you.

And that’s what I’ve been doing ever since I came back from holidays. Now I’m not so stressed; I’m still working hard and producing, but mixing in other things at the same time. With my mind less occupied, I’ve been having new ideas and more clarity; I’ve been able to think more about what I want long-term and how to get there.

I’m enjoying, I’m growing, I’m learning and I’m having fun.

And that’s all this is about. An AI agent can sit there doing nothing. The app can take another two months. Maybe some of that potential will remain unused. Who cares?

It’s ok to disconnect and live the life that’s happening around you.

Last week I had an interesting conversation about my career and how it all happened “perfectly” in alignment to get me in the great place I’m in today; however, we also explored how much my way of thinking, ambition, and my career even switched after I left Siemens, a company for which I worked for 13 years.

I spent a third of my life there. Sure, I learned and grew a lot there, mainly influenced by a few outstanding individuals who shaped my career in their early years, but looking back, I remember the times I felt like I was never going to leave, not because I couldn’t, but rather because why would I?

That kind of thinking kept me in the same place for many years, and the idea of leaving a known, comfortable place was terrifying. And I probably wouldn’t have left if not for other life-changing circumstances that happened and kinda forced me to part ways.

The same situation happened in 2022. I was working as an engineer for ZEISS, working with great people; my opinions and technical expertise were highly respected, and it was honestly a great place to work. At the same time, we had just had our second child, and I was writing for my personal blog, which peaked at over 150k views/month.

The work on my blog brought me the opportunity to join Okta as a Staff Developer Advocate, and it was a great opportunity for higher pay, working in an exciting field at a big tech company, and representing Auth0, which is an Argentinian product. But with all that going for it, I was scared, and I thought about not signing the contract multiple times because I was afraid of leaving engineering, leaving a team I was happy working with, and changing.

I eventually signed the contract, joined Okta, and promised myself I’d never let fear win; in those opportunities, going out of my comfort zone really paid off. I’m really happy I made those decisions against those primal instincts.

(I don’t have a picture of me signing to join Okta; everything was digital)

Now, not all the time I took risks worked perfectly like these instances, but I’m glad I took those risks, like starting companies, building projects, all from which I learn a lot; some of them are somewhat successful, and some of them are stories for another day.

I’ve seen many people freeze over the idea of change many times, and I get it- been there myself- and often we think about what could happen if we do change, but rarely do we think about the cost of staying.

Complacency kills your career

It is so weird that we developers are creatures of adventure and challenges, always kinda pushing into a tech zone of discomfort, and yet when it comes to our careers, we do the same job for years and are too shy or afraid to step out. And I know not every developer is like that, but it’s a common trend, and it’s pretty normal. So you have to use your brain to fight what’s basically an innate human instinct. It’s uncomfortable, but it’s a muscle you can train.

Complacency is not entirely a human phenomenon. For example, ducks normally migrate in winter because winter removes the resources they need; food and water become a lot harder to find. But when humans change the equation and keep providing those resources, some ducks will stay and avoid what they were supposed to do: migrate.

People can be the same; sometimes comfort gives us enough reason not to move, even when moving would help us grow.

But sometimes being comfortable is not a bad thing, right? After all, if you are happy in one place, why would you move? It would be unreasonable to force change. Unfortunately, many love stories end with a broken heart, and where you are happy today may not be where you are tomorrow. And that happened to me; I was very happy at Siemens at first, until I wasn’t.

The problem with complacency is that it grows over time in two ways. First, what we’ve already been discussing: the longer you are in one place, the more comfortable you are, and the more likely you are to overthink the dangers of moving on. Second, there’s another factor: reputational damage.

When someone stays so long in the same place, with the same position, people will associate that with a lack of initiative and ambition, and that’s not a good thing when you’re looking for something else. Your resume may look shallow after so many years of experience, lacking significant promotions or significant achievements to speak of. Those are definitely red flags, and they make a difference, especially now that we are in an employer’s market, and there are just so many good candidates you’ll have to stand out against for any good position.

At Siemens, I grew a lot, but it was hard to prove on my CV. Fortunately for me, I’ve always been a builder; I’ve always been proactive, and when the time came, I had a big portfolio of projects to show for it. That made a difference for me, and you? Would you have something to show for when the time comes?

Loyalty is a two-way street

A lot of the time, we employees develop a sense of loyalty toward our employers because they pay our salaries, and in a way we feel like they protect us. And that may be true for a while.

When things are going well, and we’re delivering, it’s a great relationship, but companies are not your friends or your family. You get paid your salary, and in exchange you do your job.

You can still do a great job and care about the company, the project, and the people around you. It’s absolutely ok to go the extra mile; I certainly do.

But if that’s what you decide to do, do it for yourself too. Do it because you want to become better at your craft, because you want to build something meaningful, because you want to create a reputation for yourself, or do it for your own sense of accomplishment.

Don’t give your life away because you think you owe the company something.

For a while, things can go well, but when things are getting hard because the markets change, the company changes, the team reorganizes, or anything else, believe me, the company will make the decision that is best for the company, even if that means you’re on the losing side.

Like companies will make those decisions for their own interest, you’d be able to do the same for yourself.

This doesn’t mean loyalty is not valuable, so you shouldn’t necessarily be switching jobs every six months. Staying long enough to see the consequences of your decisions, build deep expertise, and develop meaningful relationships is incredibly valuable.

But loyalty should never become dependence.

Making yourself dependable is a trap on its own

Another weird behavior tends to appear when someone has been in the same place for a long time and starts getting too comfortable. Instead of preparing themselves to move on eventually, they start doing almost the opposite; they make themselves indispensable.

I know I’ve been there, in a position where I was pretty much the only one that could fix a few of the modules we had, as I wrote the whole thing, was extremely complex, my code was efficient, but hard to understand, and I felt important because of that.

During all those years, I developed a false sense of security; it even made me cocky. I was doing what I wanted, arriving late, defying authority, all because I thought no one could touch me.

But it was only after I started helping others understand my code, coaching them into the modules and apps I’ve built over the years, that I started growing in my own position. The more I did that, the more support I got from upper management, and eventually, I was able to move into an internal position, moving countries, into a fantastic opportunity in the USA.

That experience changed how I think about being dependable and taught me a hard-earned lesson. Being dependable means people can trust you, and that builds the reputation you need to progress. On the other hand, being indispensable means the system can’t operate without you, a fallacy that turns you into a single point of failure and will get you stuck.

Being indispensable can make you feel “powerful”, as the organization often relies on you, but it’s a double edge sword, that’s not good for the organization, but more importantly, it’s not good for your career.

Experienced leaders and engineers should pave the path so they can move forward: documenting what they know, simplifying things so everyone can understand them, coaching others, and building systems that don’t require you to be involved in every decision.

I heard these arguments before, in my own head; remember that the goal is to make your current responsibilities transferable while your judgment, influence, and ability to solve new problems keep growing. It is never is to make yourself unnecessary.

Making yourself movable doesn’t mean you have to leave; it just means you finally have a choice.

Subscribe now

How do you know when it’s time for a change?

You know it’s time for a change when things are bad. When you hate going to work every morning, when you lose respect for your peers, when your health is suffering. You don’t really want anyone to tell you when you’ve reached your point.

But ideally, you don’t need to be there, and there are some signs you can look into even when you still feel good at the job.

I’m gonna show you a decision matrix I’ve used in the past to evaluate my choices, but please don’t take this as universal truth; use it as a guide to make your own analysis and decide for yourself if it’s time to move on.

Also, when doing the evaluation, don’t focus only on a bad week you’re having, or, on the other hand, an exciting conversation with a recruiter, or a flattering performance review. Look at least at what happened during the last year or two.

I like to evaluate the following areas, and I color-code each row based on how I feel about it during the evaluation period.

At the end, look at the patterns: are the green rows in the areas that matter the most to you? Do you see any reds that shouldn’t be there?

This isn’t exact science, but doing the exercise critically and visually seeing the colors can help you step back and look at the big picture of where you feel you’re at and where you can go next.

You redo this exercise quarterly, and I keep track of it, so I can also compare its evolution. Mine looks like this:

If many areas were red, especially alongside the things I care about, like growth, alignment, energy, life fit, and optionality, I’d probably start thinking about my I don’ts before the situation starts to feel bad.

Subscribe now

Change doesn’t always mean quitting

During my many years at Siemens, I worked for different teams, and I had situations where I should have left, and I didn’t, but other moments were different; they were bad, but I didn’t have to leave the company to get it fixed.

Sometimes you need a different team or project. Sometimes you get bored maintaining the same system, or you need more scope, less scope, a different manager, or sometimes it just means having a difficult conversation to help things out.

The first step is to acknowledge that something needs to change; if you are there, fantastic! But don’t rush to quit your job. Start with something smaller first, something that actually addresses the problem.

Now that you are taking action, don’t confuse that action with change.

A new project won’t fix a role without a future, or won’t change anything if you really don’t like what you’re doing. A promise of change in a year shouldn’t keep you waiting forever.

Ask for what you need to change, and set a deadline.

But be clear about what you’re asking for; if you need a new challenge, define what that looks like. If you want more responsibilities, make that ambition explicit. Have the conversation with your manager, and end with clear expectations for what will happen and by when. Agree on any checkpoints along the way so you can re-evaluate.

After that meeting, pay attention to what changes and write them down. Don’t just look at the promises; look at what actually gets delivered and how it matches the set expectations.

If the meeting doesn’t go well, or the situation after it doesn’t change, then quitting may be your best option. You don’t need to do it right away, but you should start exploring your options, interviewing, and looking for new possibilities.

So if things aren’t right, it may be time to move on!

What is a DACI?

• Driver: Moves the decision forward, gathers input, and keeps the deadline visible.

• Approver: The one person with final authority to decide.

• Contributors: The small group whose expertise is needed before the decision.

• Informed: People who need to know the outcome but do not need to join the process.

DACI does not make the decision for you. It clarifies how input becomes a decision. These role definitions follow the DACI framework described by Atlassian.

How it works

1. Log the decision as a clear question or action and set a due date.

2. Name exactly one Driver and one Approver, then add Contributors and Informed people.

3. The Driver gathers the required input and moves the status from Open to In Progress.

4. The Approver makes the call. Record the outcome and a short rationale, then mark it Decided.

Use DACI for consequential or cross-team decisions where ownership is unclear. Use a lighter process for routine choices that already have a clear owner.

Who this is for

Engineering managers, senior engineers, tech leads, and cross-functional leaders who need several perspectives without leaving the final decision ambiguous.

What is inside

• A lightweight decision log with status and due date

• Clear fields for Driver, Approver, Contributors, and Informed

• Outcome and rationale fields for the final call

• An Open Decisions view for active work and an All Decisions view for the record

Get the template

Read more

On July 21st, Substack introduced a new “Scan for AI text” feature that allows readers to scan posts to see an estimate of how much of it was written by a human, or with AI assistance. The announcement immediately sparked a wave of comments on Substack, X and Reddit, some of it applauding this feature, some of it condemning it.

The Substack Post

Against Claudefishing

It’s getting harder to tell what’s real on the internet…

Read more

3 months ago · 6853 likes · 1687 comments · Chris Best

Substack’s goal is understandable: it wants to keep the platform from being flooded with polished text that contains little human thought behind it. My concern is that a score designed to detect AI assistance can easily be read as a verdict on value, placing writers who use AI thoughtfully for research, editing, or clarity under the same suspicion as those who outsource the work itself.

At first I wanted to stay out of the conversation as writing is not something I typically cover on my newsletter, however, after thinking more deeply on the problem, I realized that I was wrong.

The very same conversation happening now between Substack and its writers, is a conversation long due in the AI world, it’s a conversation of motives and trust, about moving from generation to judgement, and that’s what this newsletter is in part about.

I’ll leave the accuracy debate to people who understand AI text detection better than I do. My concern is that even a perfect score would answer the wrong question.

A perfect score could tell us that the author used AI to generate some text, or to polish sentences, which is useful information about its process, but doesn’t say anything about the value of its contents. The fact that an author used AI doesn’t prove that the content isn’t worth reading.

And here’s where I differ with some of the anti-AI sentiment, I make a strong differentiation between AI slop, and content with actual value, where the author used AI to generate the text based on their opinion, their experiences, their knowledge or research. So if the author is able to use their judgment, and pass their views and essence while AI produces the polished result, so what?

The relevant distinction is not human vs AI, but rather assistance vs delegation.

The power of Substack as a platform compared to other social networking sites, is that substack promotes a relationship between the readers and the authors, a relationship that’s built on trust. A reader may find your notes, or come cross your article, at first there’s not trust, but curiosity, that sparks to learn more about the author, or read more of their content. Readers subscribe to an author’s judgment: what they notice, verify, recommend, and are willing to correct.

Here’s the problem that I have with the score, it doesn’t talk about the quality of the output, it only speaks about how the presentation was generated, though that may not be 100% clear to readers.

It sends the wrong message to new readers that may discard the content because the tools the author decided to use or even worse, imagine being a long subscriber from a publication, you always loved it, and now you find out the author has been using AI all along, how do you feel about that? Did the author betray your trust? Should authors be more explicit about their use of AI?

In my view, and what it comes to this publication, I use AI to assist my research, to seek for inspiration, and to validate my drafts. I write from my own experience, my own opinions and my own judgment. I don’t let AI do my thinking.

I respect every one of my reader’s time, so what I share in here is genuine contribution, it’s honest, and all I publish, I publish under my name, so I own it and I’m accountable for it. I’ve been writing before AI was a thing, at first in Wordpress, then in Markdown, used many apps, used Grammarly, now I use AI. The tools I use may change, AI makes it a lot easier, but the essence of my content will stay truly mine.

Today is a bit of a different focus, but at the end, it’s all about trust. Create a PR using AI, but own the changes. Write an essay with AI, but own what it says. If your name is on the result, you should be able to explain it, defend it, and fix it.

Thanks to all for being a reader, a subscriber, a friend!

Subscribe now

The project is a success. The pull request is clean, the design document is thorough, and the change shipped faster than expected. Yet at the six-month review, the manager still cannot answer the question that matters: what can this engineer decide now that they could not decide six months ago?

Consider a project to add automatic retries to an event-processing service. An LLM proposes a plausible design: exponential backoff, capped attempts, sensible alerts, and clean tests. The engineer turns it into a polished pull request.

During review, a staff engineer asks whether the downstream handler is idempotent. It is not. Under the wrong failure conditions, the proposed design could create duplicate side effects. The team revises the approach, and the change ships safely.

The review worked: the system is safe, and the team can operate it. What the merged pull request does not reveal is whether the engineer learned to recognize the risk, or whether the relevant judgment remained with the reviewer.

A recent discussion on X framed this as managing engineers who “don’t want to think anymore” because they delegate judgment to LLMs. The replies described polished documents with shallow reasoning, entirely AI-written pull requests with obvious flaws, and engineers appealing to model authority during disagreement: “Cursor thinks you’re wrong.”

These are practitioner anecdotes, not evidence that engineers everywhere are losing the ability or desire to think. That framing mistakes a measurement problem for a motivation problem. The same tool that removes boilerplate can recommend an architecture, weigh a tradeoff, and produce a persuasive explanation of why the decision makes sense. It never announces when assistance has become substitution.

AI may also accelerate learning by exposing engineers to alternatives and feedback they would not otherwise encounter. The management problem is not that growth cannot happen. It is that a polished artifact can hide how much of the underlying judgment developed in the engineer who submitted it.

A manager now needs to separate three outcomes:

• Did the work deliver?

• Is the decision understood and safely owned?

• Did the engineer’s judgment develop?

AI can improve the first. Review and senior oversight can protect the second. The third can remain unresolved even when the project looks entirely successful.

Output is becoming a weaker signal of growth

This problem is not entirely new. Reviewers have always corrected one another, and finished artifacts have never revealed every step of the reasoning behind them. Engineers have always borrowed judgment from colleagues, documentation, previous designs, and Stack Overflow.

AI changes the signal. It can generate both the proposed decision and a convincing account of how that decision was reached. Borrowed judgment can now arrive with the polish of independent reasoning.

If AI can help you deliver more is out of question now. Randomized field experiments involving 4,867 software developers estimated that access to GitHub Copilot increased completed tasks by 26.1 percent. The experiments did not measure understanding, code quality, or long-term capability, but they provide strong evidence that AI assistance can create real leverage.

Other research suggests that the cognitive work is moving. A Microsoft Research and Carnegie Mellon study asked 319 knowledge workers about 936 examples of using generative AI at work. Participants described critical thinking shifting toward verification, integration, and oversight. A 2026 longitudinal preprint about professional software engineers similarly describes a shift from creation toward directing, evaluating, and correcting AI output.

None of these studies shows that engineers are learning less. They measured completed work or workers’ descriptions of how their work was changing, not long-term judgment. Together, they explain why completed work is becoming a weaker proxy for individual development.

A correct answer does not, by itself, demonstrate engineering growth. Growth becomes visible when someone forms a view, encounters evidence or disagreement, updates that view, and carries the lesson into a different problem. If a model proposes the approach and a senior reviewer repairs its weak assumptions, the system may be safe while the author’s mental model remains unchanged.

A model can also produce the design rationale, the rejected alternatives, and the explanation for why the eventual decision was correct. The work may look thoughtful without showing whether the engineer can reproduce the thinking when the conditions change.

Subscribe now

Managers cannot inspect their way out

Prompt logs can answer compliance questions. They cannot answer growth questions. They show how something was produced, but not whether the author can adapt when the generated answer stops matching reality.

An unaided presentation has a different weakness. It may reveal local understanding, but it also rewards verbal confidence and can become a ritual in which engineers perform comprehension for senior reviewers. Applied to every meaningful change, it turns the most experienced people on the team into permanent approval gates.

Strong engineers can delegate large amounts of implementation while retaining a clear model of the system, its constraints, and its failure modes. Another engineer can write every line manually and still exercise poor judgment. How much AI someone used is not a useful substitute for evaluating what they can decide.

Even “Cursor thinks you’re wrong” is not a problem because Cursor must be wrong. The model may have surfaced a valuable objection. The problem is that the objection has not been converted into inspectable evidence and an owned recommendation.

The immediate coaching questions should be straightforward:

• What do you recommend?

• What evidence can we verify?

• What would change your mind?

The engineer can use the model while answering. The manager is looking for ownership of the decision, not proof that the engineer worked alone.

Organizational incentives complicate this further. If a company demands visible AI adoption, rewards throughput, and treats hesitation as resistance, engineers will reasonably reach for a model before forming their own view. Management cannot punish the pause and then blame people for skipping the thinking that might have happened inside it.

Managers need evidence of development without creating surveillance. That evidence appears across time, not inside a prompt transcript.

Review one decision twice

A better way to evaluate growth is to revisit one consequential decision twice: once while it is open and once after the outcome is visible.

The first review can happen inside an existing design discussion. The engineer captures:

• their recommendation;

• the key uncertainty;

• the evidence that would cause them to change direction.

A staff engineer or teammate familiar with the system then challenges the premise. The point is not to pre-approve the decision. It is to expose the assumption the decision depends on.

The second review can happen in an existing retrospective or one-on-one. Ask:

• What surprised you?

• Which assumption failed?

• What will you investigate earlier next time?

Return to the retry example. The useful evidence is not that the engineer can now define idempotency. It appears later, when another project involves message reprocessing and they raise the duplicate-effects risk before somebody else has to ask. The lesson has moved from one corrected pull request into the engineer’s judgment.

An LLM can help write the initial decision note. That does not undermine the exercise because the note is only a marker. The evidence arrives afterward: the engineer notices a related risk sooner, changes direction when the facts change, adapts the lesson to a different system, or helps another person reason through the same tradeoff.

This should be selective. Reviewing every ticket would create another approval process and concentrate an invisible coaching tax on the same senior engineers. Managers should reserve the practice for consequential, uncertain, or difficult-to-reverse decisions.

They should also protect time for the coaching involved and ensure that useful technical challenges become developmental feedback rather than disappearing inside pull-request comments.

For a growth conversation, a few examples of transferred judgment are more diagnostic than a complete inventory of AI-assisted tickets.

What should be visible six months later

The useful question is not whether if engineers “want to think.” It is how to manage when thinking can be skipped without making the output look unfinished—and when the organization may reward the output before anyone notices.

Preserving every manual step would confuse effort with learning and discard genuine leverage. The management responsibility is to preserve the parts of engineering work where people form a view, encounter disagreement, revise their assumptions, and transfer what they learned.

That changes what counts as evidence in a performance conversation. Completed work still matters. So does recognizing a failure mode earlier, changing a recommendation when the facts change, applying a lesson in a new context, and helping somebody else make a better decision.

These signals are less convenient than counting pull requests. They are also closer to the capability a team will need when the next problem no longer resembles the last one.

A growth review should not ask how much of the engineer’s work was generated. It should ask what this engineer can now decide that they could not decide six months ago, and what evidence shows they can carry that judgment into the next problem.

For most of my career, I was an individual contributor. Usefulness was visible: write the code, review the change, fix the problem, publish the document. The output was easier to see.

Moving into management changed that relationship before I had a good way to think about the calendar. A 1:1, a proposal review, a stakeholder question, and an escalation can all be legitimate work. Put enough of them together, though, and the week disappears before the decisions and conversations that require a lead have room.

The transition problem starts when leadership work arrives before old IC work leaves. Implementation, routine review, technical coordination, and familiar context remain attached through habit; people, delivery, feedback, stakeholders, and risk arrive on top. This is not a time-management problem in the narrow sense. It is a responsibility problem expressed through the calendar.

This guide is for new engineering managers and technical leads whose outcomes increasingly depend on other people while they still carry part of their old role. Their authority differs, but the practical question is the same: which work genuinely requires your attention, and which work is still yours because it used to be?

My operating rule is simple: when leadership work enters your week, work from your old job needs to leave. A transition may require temporary overlap, but temporary overlap needs an end date. Otherwise it quietly becomes two permanent jobs.

Audit the week you actually have

For an initial audit, do not start by designing an ideal calendar. Start with the previous ten working days.

Open your calendar, Slack, notes, and whatever you use to track work. Account for visible commitments and the work around them: preparing feedback, reviewing proposals, answering questions, writing follow-ups, recovering context between meetings, handling an incident, or finishing something after hours because it never found space during the day.

You do not need a new time-tracking system. The goal is not minute-by-minute surveillance. You are looking for enough evidence to answer five questions:

1. What took meaningful time?

2. What outcome did it create?

3. Why did it require me?

4. Who waited for me?

5. Should I own it, stay close to it, transfer it, or stop it?

A simple audit might look like this:

The “Why me?” column is uncomfortable because familiarity can masquerade as responsibility. You may be the fastest reviewer because you know the codebase. You may be the best person to rewrite a plan because you have stronger opinions about its structure. Neither fact automatically means the work should remain yours.

Look for three forms of calendar pressure:

• Hidden leadership work: feedback, tradeoff decisions, stakeholder preparation, and thinking that gets pushed outside working hours.

• Habitual IC work: implementation, routine review, or technical coordination you still own because you used to own it.

• Recurring demand: meetings, approvals, and repeated questions that keep returning because the underlying ownership or context is unclear.

At the end of the audit, name the three biggest sources of pressure. Do not fix all of them yet. The audit separates what feels busy from what is making the team dependent on you.

Stop carrying your old job

Push each recurring responsibility to the lowest level of involvement that is still safe. Then sort it into four groups.

Own. Work that requires your authority, accountability, or sensitive judgment: a performance conversation, a priority conflict, a cross-team commitment, a high-risk escalation, or a decision where the team needs one accountable owner.

Stay close. Work where you need enough context to exercise judgment without controlling every step: an important launch, a migration with operational risk, architecture with long-term consequences, or a customer problem that could change team priorities.

Transfer. Give another person a complete outcome when the work can develop their judgment and reduce unnecessary dependence on you: routine reviews, project coordination, implementation planning, recurring documentation, or a technical proposal.

Stop. Meetings without an output, duplicate reports, inherited approvals nobody can justify, and processes that cost more attention than the risk they manage.

These categories do not make technical work inappropriate. A technical lead might keep implementation when it reduces important risk, establishes a reusable pattern, or supplies context that would be expensive to gain another way. An engineering manager might stay close by inspecting risk and decision quality without becoming the routine reviewer or implementer. The test is whether lead-level attention changes the outcome, not whether the work is technical.

Treat Own as the uncomfortable “only I” list, then challenge every item in it. Does it truly require your authority? Is the information sensitive? Is the decision hard to reverse? Is the risk high enough that you need to own the call? If the answer is no, the work may need your context or a checkpoint, but it probably does not need your hands.

Do not remove yourself so aggressively that high-risk work loses necessary context. Transferring a security-sensitive change and then disappearing creates an accountability gap. Match your involvement to the person, the risk, and the reversibility of the decision.

For the next week, choose one item to stop, one to transfer, and one to stay close to through a lighter mechanism. If Own still contains half the role, go through it again. You may be protecting a preferred method rather than a necessary responsibility.

Budget your week before it fills

Once you know what should remain yours, build the week around responsibilities rather than incoming requests.

Start with the commitments that are genuinely fixed: 1:1s, team planning, interviews, an operating review, or a launch decision with an external deadline. Add preparation time for the commitments that need it. A one-hour feedback conversation is not a one-hour piece of work if you need thirty minutes beforehand to review examples and decide what you actually want to say.

Then add the work that is important but easy to displace:

• decisions and tradeoff preparation;

• consequential technical context;

• difficult conversations;

• written context that will prevent repeated explanation;

• delegation checkpoints;

• support or escalation requests to your manager.

Some of this work deserves a name: judgment time. It is where you compare weak signals, prepare consequential feedback, inspect technical risk, and decide which tradeoff you are willing to defend. Without a named block, visible tasks and incoming requests can repeatedly displace it.

Create an operating reserve. As a starting experiment, reserve 10–20% of your sustainable week if you can, then adjust it through the weekly audit. A team with frequent on-call interruptions may need more. A lead with little control over the calendar may begin with one open half-day. The point is to treat incidents, escalations, and work that runs long as normal operating conditions rather than planning failures.

The arithmetic has to work. If your plan contains forty-six hours of commitments, a better color scheme will not turn it into a forty-hour week.

Consider a hypothetical new engineering manager with seven reports, a migration in progress, and normal on-call exposure:

The numbers are illustrative. A tech lead may need more technical time; a manager with a larger team may need more people-management time. The important change is what left, not the allocation itself.

Before moving on, make the budget balance:

1. Subtract fixed commitments, preparation, and the operating reserve from your sustainable weekly capacity.

2. Allocate what remains across people, decisions, technical context, stakeholders, and administration.

3. Remove, reduce, or transfer work until the total fits without relying on evenings.

Block your time

Calendar blocks help only when they protect a named outcome. “Focus time” is too vague. It is easy to overwrite because nobody, including you, knows what would be lost.

Use specific names:

• Review the migration risk and decide whether to phase the launch.

• Prepare feedback for Thursday’s 1:1.

• Read the API proposal and write the decision boundary.

A useful block also needs an interruption rule and a response window. For example:

I am using 9–11 to prepare feedback and make the release decision. Interrupt for a production incident, an urgent people issue, or a decision holding up several people. Otherwise, add it to the queue and I will respond by 2.

This keeps protected time from becoming unavailability. The team knows what may interrupt it and when other requests will receive attention.

Block three things in the next week: one decision, one consequential conversation, and one technical risk. That is enough to test the shape without turning the calendar into a fortress.

Do not protect personal output while the team waits for a decision only you can make. If five engineers are blocked on a release call, move the writing block, make the call, and restore the time somewhere visible. Protect important work from accidental displacement, not every calendar event.

If the same “temporary” meeting overwrites a block every week, the block is not protected and the meeting is not temporary. Resolve the conflict instead of maintaining the fiction.

Read more

This resource turns that transition into a structured table. It groups the work into clear management areas, names the expectation behind each topic, and gives you space to record evidence, context, and your next move.

Who this is for

First-time engineering managers and experienced managers entering a new team who need a practical way to decide what deserves attention now, what can wait, and what evidence would show progress.

What is inside

• More than 60 management expectations across team and trust, delivery and quality, collaboration and communication, direction and planning, and manager growth

• A clear Topic and Expectation for every row

• A Notes and examples column for evidence, context, or your next action

• An interactive Done checkbox for each expectation

• Review guidance for choosing a few priorities and revisiting them around days 30, 60, and 90

The point is not to check every box. Review it with your manager, choose a few priorities at a time, and adapt it to your business context, team structure, and team dynamics.

Get the checklist

Read more

Who this is for

Senior engineers and engineering leaders making decisions that create meaningful work, risk, or maintenance after implementation.

What is inside

• A decision log with the date, status, owner, and revisit date

• A repeatable worksheet for the problem and options considered

• Prompts for immediate benefits, costs that may appear later, and reversibility

• Space to record the eventual outcome

Get the template

Read more

Who this is for

Use it when starting a Staff or tech lead role, taking responsibility for a new initiative, or resetting expectations after the role has begun to drift.

What is inside

• The role and why it exists

• No more than three expected outcomes

• Clear ownership, shared decisions, and out-of-scope work

• Technical involvement, support, capacity, and measures of success

Get the template

Read more

Who this is for

Senior engineers and engineering leaders who want more than a one-time career worksheet. Use it when you know you want to grow but need a clearer way to connect that direction to real work, evidence, and regular review.

What is inside

• A career direction section for the work you want more and less exposure to

• Two or three objectives for the next 6–12 months

• A focused 90-day responsibility or skill to practise through real work

• A five-field goal tracker for Area, Status, Target date, and Next review

• A reusable goal page for actions, evidence, support, and review notes

Get the template

Read more

Who this is for

Use it if you are a senior engineer whose impact spans projects, decisions, mentoring, incidents, or cross-team work. Add an entry after meaningful work, then return to the log before career conversations and performance reviews.

What is inside

• A simple log with Entry, Date, Category, Scope, and Evidence

• A repeatable entry page covering Situation, What I did, Result, Evidence, and What this shows

Get the template

Read more

Who this is for

Engineering managers and other people leaders who want simpler meeting notes and clearer follow-through. Use it when useful context and action items are getting lost between conversations.

What is inside

• A meeting tracker with the date, an optional feeling check, and action-item status

• A repeatable agenda for what is going well, what is not going well, and feedback

• Dedicated space for action items and additional notes

Get the template

Read more

A product lead wants a natural-language setup flow for a developer tool. One engineer thinks it could remove most of the friction from the first integration. Another worries that authentication, error recovery, and the current SDK contracts will make the experience brittle. A staff engineer sees a different risk: if the demo looks convincing, it may become a roadmap commitment before the team understands what it would take to operate.

The team could spend another week improving the design document, or it could build a narrow prototype and put the disagreement in front of real evidence.

AI changes the economics of that choice. For throwaway prototypes, I have felt the speed gain directly: a proof of concept that once took two or three days can now land in an afternoon. That makes implementation cheap enough to use during the decision process, not only after the decision has already been made.

But AI makes the artifact cheaper, not the evidence. Once people can click through the flow, call the API, or watch the agent complete a task, the discussion shifts from “Should we build this?” to “What would it take to ship what we already have?”

The artifact has started answering a question nobody agreed to ask.

My recommendation is to build the disagreement when implementation can produce evidence, but treat the prototype as an expiring question rather than an early product. Before anyone prompts an agent, define what the prototype may prove, which shortcuts limit that conclusion, when its mandate ends, and what happens to the implementation afterward.

None of this is unique to AI. “What Do Prototypes Prototype?” frames prototype focus as a choice about which open design questions to examine, while “The Anatomy of Prototypes” describes prototypes as filters over a broader design space. AI changes how quickly a functional, convincing artifact can appear—and, I would argue, the organizational pressure to treat an answer-shaped artifact as a product.

When this rubric is worth using

Not every sketch needs a formal hypothesis. If two engineers are exploring a low-risk implementation detail for an hour, let them explore.

Use the rubric when the artifact could influence:

• roadmap scope or a customer promise;

• an architectural or integration decision;

• a production or security boundary;

• a cross-team commitment;

• a claim about user behavior;

• whether generated code becomes part of a maintained system.

Subscribe now

The point is proportionality. Five lines written before two days of implementation are not heavy governance. They protect the team from spending the next six months maintaining an answer to the wrong question.

The prototype decision card

Every consequential prototype should begin with five fields:

1. Question

2. Evidence

3. Shortcuts

4. Expiry

5. Disposition

This is not a new approval process. The decision boundary must travel with the artifact. Keep the card inside the issue, design document, or pull request description, and put the question, expiry date, and status on the prototype itself. A forwarded link, screenshot, or recorded demo should still say what the artifact was designed to test and whether it is approved for production or customer commitments.

Prototype for: Expired-credential recovery

Expires: 18 July

Status: Not approved for production or customer commitments

Decision card: Linked with this artifact

1. Question: What decision should change?

Name one decision the prototype will inform.

“Can we build this?” is usually too broad. Almost anything can be made to work once under favorable conditions. Narrower questions force the team to identify the disagreement underneath the implementation:

• Can a target developer finish the first integration without leaving the guided flow?

• Does the current API contract support recovery from an expired credential?

• Can this architecture meet the latency target when one dependency degrades?

• Can the agent handle the representative failure cases without taking an unsafe action?

A useful question has consequences. Before building, state what the team will do after a positive result and what it will do after a negative one:

If the result is positive, we will [action]. If it is negative, we will [action].

If neither result would change the decision, the team is not running an experiment. It is producing a demonstration. If the evidence lands between the predeclared criteria, call the result inconclusive and write a new card rather than rewriting the first question.

2. Evidence: What would count as an answer?

State what the team will observe or attempt, who will do it, and which results will count as positive, negative, or inconclusive. Define those criteria before seeing the artifact, so the team cannot move the goalposts after the prototype starts persuading people.

The evidence must match the question. A usability claim requires target users attempting the task. An operational claim requires load, failure, recovery, or maintenance evidence. A claim about agent reliability requires a representative evaluation set, not one impressive trace selected for the demo.

In “Prototyping with Prompts”, a CHI 2025 design study, researchers observed 39 industry practitioners across 13 team sessions as they prototyped prompts for a generative AI marketing application. The authors describe two layers of evaluation: teams assessed output validity and correctness while considering whether end users could understand and meaningfully interact with it. They also found that assumptions about cultural norms, user behavior, content formats, and conceptual abstractions could remain implicit and undocumented. This suggests that greater fidelity can expand what a team is able to inspect, but it does not determine which evidence a decision requires.

3. Shortcuts: What is intentionally unlike production?

List every condition that is fake, stubbed, omitted, unreviewed, not tested at scale, incomplete, or unusually favorable.

Typical shortcuts include:

• mocked billing or permissions;

• a test tenant instead of a real account;

• one supported language or environment;

• clean data that excludes known edge cases;

• no production secrets or security review;

• a single happy path;

• manual intervention hidden behind an automated-looking flow;

• generated code nobody has reviewed for maintainability.

Shortcuts are not a failure. They are what makes a prototype cheap. But a shortcut may only narrow the conclusions the team can draw; it cannot waive non-negotiable privacy, security, legal, or safety requirements.

Mocked billing may be irrelevant to a navigation test and fatal to an integration-feasibility claim. A test tenant may be enough to inspect the interaction and useless for understanding production permissions.

For each shortcut, ask: “Which conclusion are we no longer allowed to draw because this is fake?”

4. Expiry: When does the experiment end?

Give the prototype a time, budget, or learning limit.

Examples:

• two days of implementation;

• five user sessions;

• one load-test cycle;

• twenty representative agent tasks;

• confirmation of one API behavior;

• the first unrecoverable security constraint.

Without an expiry, a prototype tends to keep absorbing work. Someone adds another path because the first one looked promising. Another engineer improves the error handling. A stakeholder asks whether it can be shown to a customer. The team quietly stops learning and starts developing, but the code never passes through the decisions expected of a real product.

An expiry does not mean the idea must die. It means the current artifact loses its mandate. Continuing requires a new question, a new experiment, or an explicit production proposal.

5. Disposition: What happens to the artifact?

Decide in advance whether a positive result leads to:

• a clean rebuild;

• a separate production proposal;

• another experiment;

• retention of only the findings or test fixtures;

• a deliberate stop.

A prototype should not enter production because rebuilding feels wasteful. If the implementation is worth keeping, it should earn that decision independently through normal review, security, testing, ownership, and operational standards. The prototype label should not grant generated code a permanent exemption.

When the expiry condition arrives, append a short closeout to the card:

• Result: What happened against the predeclared criteria.

• Decision: What changes now.

• Artifact status: Deleted, archived, retained for evaluation, or proposed for independent review.

• Owner and date: Who closed the experiment and when.

The closeout is not a sixth planning field. It is the durable record that stops later readers from reinterpreting the artifact after its context has faded.

In “From Throw-Away to Takeaway”, a CHI 2026 mixed-methods study combined an online survey of 85 people with interviews of 31 hackathon participants and eight practitioners. In its sample, cloud development environments accelerated prototyping and enabled non-technical users to create high-fidelity throwaway prototypes for experiential exploration. Deployment and long-term maintainability, however, continued to depend on technical expertise. The study supports separating prototype evidence from production readiness; it does not show that this five-field card improves team decisions. The card is my operating recommendation.

Subscribe now

Match the evidence to the prototype

Vision prototypes belong in this model even when they are not experiments. Their evidence is discussion and alignment. Stakeholder enthusiasm shows that an idea is persuasive; it does not validate user need, technical feasibility, or roadmap priority.

A completed decision card

Return to the developer-tool disagreement from the opening. Instead of asking an agent to “build a natural-language onboarding flow,” the team writes this first:

Question: Can a target developer complete the first integration—including recovery from an expired credential—without leaving the guided flow, using the current API contracts?

Evidence: Five target developers attempt both a clean setup and a scripted expired-credential case in a faithful test environment. A positive result means at least four complete both cases within fifteen minutes without manual backend intervention. A negative result means the current contract cannot support safe in-flow recovery, or more than one participant reaches an unrecoverable error. Any other result is inconclusive. The team records completion time, confusion, help requests, manual intervention, and unrecoverable errors.

Shortcuts: Test tenant only. Billing is mocked. One language is supported. No production secrets or customer data are used. The prototype makes no claim about scale, security approval, or maintainability.

Expiry: Two days of implementation and five user sessions, or immediate termination if the current contract cannot support safe in-flow recovery.

Disposition: A positive result leads to a separate production proposal and an independent decision about whether any implementation is retained. A negative result preserves the findings and evaluation fixtures, then deletes or archives the prototype. An inconclusive result requires a new card.

Now the team knows both what success means and what would falsify the experiment. A beautiful demo cannot settle the question if no target developer attempts the integration. A successful happy path cannot hide an API contract that makes recovery impossible, because recovery is part of the evidence plan. A weak result does not automatically kill the broader idea; it may show that the current contract, not the interaction, is the next question to investigate.

After the sessions, the closeout might read:

• Result: Four of five developers completed the clean path; only two recovered from an expired credential, and three reached an unrecoverable error.

• Decision: Stop the onboarding prototype and investigate the API contract.

• Artifact status: Prototype archived; evaluation fixtures retained.

• Owner and date: Prototype lead, 18 July.

The failure modes to watch

• The sales demo is built to persuade and later cited as validation. Label vision and sales artifacts explicitly, including what they were never designed to test.

• The happy-path proof shows that something can work once and becomes evidence of production readiness. Record which properties—load, recovery, security, observability, and maintainability—remain outside the experiment.

• The moving question appears when the team rewrites the hypothesis after seeing the result. Preserve the original card; if the artifact reveals a more useful question, create a new one.

• The evidence mismatch uses the wrong people or conditions. Internal stakeholders cannot validate customer usability, and a mocked API cannot validate current integration behavior.

• The accidental foundation begins with “We already have most of it.” Require an independent production decision. Do not measure waste by lines of prototype code deleted.

• The orphan prototype survives after the decision with no owner or status. Make cleanup part of the disposition and record the artifact’s status in the closeout.

What to do before the next prototype

Before anyone starts building, ask the team to spend ten minutes on the decision card.

During the experiment, record observations and newly discovered shortcuts. Do not expand the prototype merely because implementation is going well.

When the expiry condition arrives, stop and complete the closeout. A positive result should change only the decision named on the card. A negative result is useful when the test was valid. An inconclusive result means the question or evidence plan needs another pass.

AI makes it cheaper to turn disagreements into things a team can inspect. The prototype should earn authority from the evidence it collects, not from how much it resembles a finished product.

Before the next agent starts generating code, decide what its artifact is allowed to prove—and what your team has already agreed to do when the question expires.

That question can be healthy. Some engineers still underuse tools that would remove boring work, surface options, or force a sharper explanation of the problem. I do not think engineering leaders are wrong to expect people to learn AI. Refusing to build any muscle with these tools is becoming its own professional risk.

The problem starts when “AI-first” becomes a test of seriousness. Once the expected answer is visible, people learn to produce that answer. They mention the tool in planning. They add it to the workflow where it can be seen. They show the demo. They write the performance-review paragraph. The company gets evidence of adoption before it gets evidence that the work improved.

Luiza Jarovsky’s essay, When AI Becomes a Religion, is too broad for the exact piece I want to write, but it names a pattern worth taking seriously inside companies: salvation language, dogma, and the awkward role of the heretic. I would not import the whole religion frame into engineering. It gets noisy quickly. The workplace question is what happens when skepticism starts to carry a social cost. The engineer who asks for evidence, slows a rollout, or says the generated code made review worse can start to look behind the culture, even when they are protecting the feedback loop the organization needs.

Shopify is a useful public example because it turns the cultural pressure into an operating rule. In April 2025, coverage from Business Insider and The Verge described a memo from CEO Tobi Lütke that made AI usage a baseline expectation, asked teams to show why work could not be done with AI before requesting more headcount or resources, and added AI usage questions to performance and peer review. There is a reasonable version of that management instinct. Headcount should not be the default answer when tools and workflow changes can absorb some of the work. A serious organization can expect people to try available leverage before asking for more capacity.

The failure mode starts when proof of trying becomes more important than the quality of the result. If a team knows the safest answer is “yes, we used AI,” then people will learn how to produce that answer. They will add the tool to the workflow, mention it in planning, show a demo, or include it in a review packet. That may be sincere learning. It may also be adoption theater. From the outside, both can look similar unless leaders measure what happened downstream.

When usage becomes safer than judgment

Usage is attractive because it is legible. Licenses activated, prompts submitted, features shipped with AI assistance, agents connected to repositories, demos shown in all-hands meetings. These numbers make the rollout visible. They do not prove that the organization is building better software.

The Stack Overflow 2026 pulse survey is useful precisely because it holds two ideas together. Workplace agent usage had risen: 59% of respondents said they used agents at work, nearly double the 31% Stack Overflow reported from its 2025 Developer Survey. At the same time, 63% of technologists said they rarely or never let agents run fully on autopilot. The survey was self-reported and had 1,100 respondents, so I would treat it as directional. Still, the tension is the one engineering leaders need to understand. Adoption is real, and supervision is still doing a lot of the work.

If leadership celebrates usage while the work still requires supervision, the supervision still has to happen somewhere. It usually lands with senior engineers, reviewers, tech leads, and managers who have to decide whether the generated output is correct enough to ship. The prompt may be faster than writing the first draft of the code. The review can still become slower, especially when the author cannot explain the change, the test is brittle, or the diff is plausible in ways that make mistakes harder to spot.

Moreover, DORA’s 2025 AI-assisted software development report pushes the conversation away from tool access alone and toward the system around the tool. Local productivity gains matter only if they translate into product performance instead of downstream chaos. A team can produce more code-shaped output and still make the engineering system worse.

There is also a social layer. AI tools are not neutral calculators inside a team. OpenAI’s post on sycophancy in GPT-4o is a reminder that model behavior can affect trust: the company rolled back an update after GPT-4o became too flattering and agreeable. A tool that agrees too easily can make a weak plan feel stronger than it is. A company culture that rewards visible AI enthusiasm can do the same thing from the other side. The model says the plan is good. The dashboard says adoption is up. The executive story says the team is modernizing. The reviewer who says “this is not ready” becomes the inconvenience.

Subscribe now

What I would measure instead

If I were accountable for an AI rollout, I would not ask teams to prove they are bought in. I would ask where AI made the engineering system measurably better and where it shifted cost out of sight.

For code review, I would look at whether reviewers are catching better issues or just reading more generated diffs. For incident response, I would look at whether AI-assisted summaries improved diagnosis without flattening uncertainty. For onboarding, I would look at whether new engineers reached useful context faster and whether they could still explain the systems they touched. For migrations and maintenance work, I would look at whether generated changes reduced toil without increasing the burden on the people who own the code after the migration lands.

Those questions are slower than adoption dashboards, but they are closer to the work. They also leave room for the honest positive case. Sometimes AI will be the right answer. It can remove blank-page friction, draft tests, summarize unfamiliar code, produce a first pass at support tooling, and make a senior engineer faster when the senior engineer still owns the judgment. The critique is aimed at pressure that creates bad data.

A useful leader should want the bad data. Failed prompts, wrong assumptions, unreviewable patches, brittle generated tests, and moments where the tool made someone faster but less clear about the work are not signs of disloyalty. They are rollout telemetry. If people hide those signals because skepticism sounds like resistance, the organization loses the information it needs to adopt AI well.

Protect the useful skeptic

In an engineering organization, the useful skeptic is often not trying to stop adoption. They are asking the question that keeps adoption honest. What got better? What got worse? Who absorbed the review cost? Which failure mode disappeared, and which one moved to production? Did the team learn a reusable workflow, or did one person get a private boost that nobody else can inspect or improve?

That distinction matters for senior engineers. A senior engineer who pushes back on a shallow AI mandate should not sound anti-tool. The stronger posture is more demanding: show me the outcome, show me the review path, show me what we learned, and show me where the tool made the system less reliable. That is not nostalgia for pre-AI engineering. It is the production discipline we should have been using all along.

It also matters for managers. If “AI-first” becomes a loyalty test, managers will get the answers they trained the organization to produce. People will describe their work in AI-friendly language. They will use the tool where the tool is visible. They will avoid being the person who sounds slow, difficult, or unconvinced. The organization may feel aligned while its feedback loops get worse.

The healthier version starts with the work: the workflow, the risk, the customer outcome, the review burden, and the learning the team needs to keep. Then ask where AI helps and where it creates a new failure mode. Engineers do not need permission to be curious about AI. They need permission to report the truth about it.

That is the line I would want leaders to protect. Push people to learn the tools. Do not punish the people who keep the evidence honest. In a serious engineering organization, the person who refuses to turn usage into faith may be part of the control system that makes adoption work.

We built chains, graphs, routers, callback handlers, retrievers, memory abstractions, evaluation layers, and handoff nodes. Some of that was necessary. If an AI system moves money, changes permissions, updates customer data, deploys software, or touches production infrastructure, the hard boundaries belong in code. Nobody should trust a paragraph in a Markdown file to enforce access control.

But we took that instinct too far. A lot of AI application behavior is not a hard boundary. It is procedure, policy, tone, source discipline, review expectations, escalation rules, examples, and handoff shape. Those are the parts of a workflow that change often, depend on domain judgment, and are usually maintained by people who should not have to modify orchestration code to make the product behave better.

That is the mistake I think the first wave of AI apps made: we treated too much of the AI layer as an orchestration problem. The future is simpler than that. Code should provide the harness. Markdown should carry much more of the work.

That is what I mean when I say Markdown is becoming the application layer of AI apps. I do not mean Markdown replaces Python, TypeScript, Go, SQL, permissions, tests, queues, schemas, or production controls. I mean the part of the product that tells the AI system how to behave is moving out of framework code and into written, versioned instructions that humans can read and agents can execute.

The transition is from code-heavy orchestration to harnesses plus Markdown.

The First Version Was Too Much Code

The framework-heavy approach made sense at the beginning. Early AI applications needed scaffolding because the raw model interface was too loose. Retrieval needed structure. Tool calling needed wrappers. Production teams needed traces, retries, typed inputs, fallbacks, and evaluation hooks. LangChain and LlamaIndex became natural choices because they gave engineers a way to turn an uncertain model interaction into something that looked more like software.

I do not want to turn those frameworks into cartoon villains. They are useful libraries. LangChain has real orchestration and integration machinery. LlamaIndex is useful for indexing, parsing, retrieval, and data-connected applications. Both ecosystems support Markdown as an input format, whether through LangChain’s UnstructuredMarkdownLoader or LlamaIndex’s Markdown node parsers.

The problem is not that these tools exist. The problem is the reflex they encouraged: when an AI workflow becomes important, encode the next decision as another node. That works when the workflow is stable and the branches are genuinely software branches. It gets awkward when the workflow is really a written policy that people keep learning how to improve.

A support escalation rule should not always require a framework change. A source policy should not be buried in a callback. An editorial standard should not live as a prompt string in application code. A review checklist should not be scattered across several agent nodes. When those things live in code, the people closest to the domain lose the ability to improve them directly. The workflow becomes more formal, but not necessarily more maintainable.

This is how teams end up with an AI system that is technically sophisticated and operationally clumsy. The code can call the model, fetch the documents, route the task, and produce an answer. But changing what “good” means still requires spelunking through framework glue, prompt fragments, and hidden assumptions.

Subscribe now

The Simpler Shape

The simpler architecture has three parts.

First, product code still owns capabilities and constraints. It defines the APIs, data access, permissions, transactions, schemas, audit logs, deployment paths, and anything else that must be reliable even when the model is wrong.

Second, the agent harness gives the model a safe place to operate. The harness decides which tools exist, which files can be read, what state is available, how approvals work, how traces are captured, how evals run, and where the system should stop instead of guessing.

Third, Markdown carries the operating behavior. This is where the workflow lives: the source policy, the escalation rules, the examples, the templates, the product vocabulary, the review expectations, the domain caveats, and the handoff contract.

That split matters because it puts the right kind of change in the right kind of medium. If the change must be enforced, it belongs in code. If the change teaches the AI system how the team wants work done, Markdown is often a better place for it. It is easier to review, easier to diff, easier to search, and easier for domain owners to maintain with engineering guardrails around it.

This is not no-code. It is not “let the prompt handle it.” It is a different ownership model: engineers build the harness and enforce the boundaries; the Markdown layer describes the work the harness should perform.

What Moves From Code To Markdown

The useful way to think about the transition is not “which language are we using?” The useful question is “what kind of decision is this?”

Code should own the decisions that need deterministic enforcement: permissions, data writes, destructive actions, money movement, external side effects, compliance checks, schema validation, deployment, rollback, and anything where being merely persuasive is not good enough.

Markdown can own a different class of decisions: how to investigate a bug, how to write a release note, what sources count as reliable, when to escalate a customer issue, what a good support answer looks like, how to compare devices, how to produce an editorial brief, how to prepare a pull request handoff, or how to explain a product feature without overpromising.

Those second-order decisions are still important. In many AI products, they are the product. A customer assistant that follows the wrong escalation policy is not a small UX problem. A research agent that treats vendor claims as neutral evidence will produce bad work. A coding agent that writes a migration without the team’s review expectations is creating risk. But the way to improve those behaviors is not always another code path. Often it is a clearer workflow, a better example, a tighter source policy, or a more explicit handoff template.

That is why Markdown matters. It is the medium where those instructions can become part of the application without disappearing into framework glue.

Why This Is Happening Now

Vercel’s Eve is the cleanest public example of this direction. Eve describes itself as a filesystem-first framework for durable AI agents. A typical Eve agent has an agent/instructions.md file as the always-on prompt, optional Markdown skills that can be loaded on demand, typed tools, channels, and schedules. The important thing is the authoring surface: the workflow is not primarily a visual graph or a chain of Python objects. It is a filesystem with Markdown instructions and skills.

OpenAI and Anthropic are moving toward the same split from the harness side. The OpenAI Agents SDK gives applications primitives for agents, tools, handoffs, guardrails, sessions, tracing, and human approval. The Codex SDK lets applications control local Codex agents programmatically. Anthropic’s Claude Agent SDK exposes the agent loop, tools, permission model, session management, MCP support, hooks, subagents, and filesystem-based configuration that power Claude Code.

Those SDKs are not Markdown frameworks. That is not the point. The point is that the harness is becoming product infrastructure. Once a product has a capable harness, the next question is where the product-specific behavior should live. My bet is that a lot of it will live in Markdown.

The instruction file conventions are already normalizing. Codex reads AGENTS.md for project instructions. Claude Code uses CLAUDE.md for persistent project memory and can import AGENTS.md to avoid duplicated guidance. Google’s Open Knowledge Format draft describes knowledge bundles as directories of Markdown files with YAML frontmatter, meant to be readable by humans, parseable by agents, diffable in version control, and portable across tools.

These are not the same thing. AGENTS.md, CLAUDE.md, Eve’s instructions.md, llms.txt, OKF bundles, and framework document loaders all have different scopes and loading rules. But they point toward the same underlying shape: humans write structured text, agents use it as operating context, and the product changes when that text changes.

There is also research pushing in this direction. The March 2026 paper “Interpretable Context Methodology: Folder Structure as Agentic Architecture” argues that, for sequential workflows with human review, folder structure and Markdown prompts can replace some framework-level orchestration. I would not stretch that into a universal rule. Complex concurrent systems still need real orchestration. But the paper matches a pattern many teams will recognize: a lot of useful work is sequential, review-heavy, and easier to inspect when the process is visible in files.

Subscribe now

What This Looks Like In Practice

My own content system has pushed me toward this view. The Long Commit has a private Markdown operating layer: root instructions, voice rules, research standards, workflow files, templates, source policies, and Notion handoff rules. One workflow follows the sources I care about and produces a daily brief. The brief is not the article. It is a prepared starting point: what happened, where the primary sources are, what might be worth reading, and where the evidence is weak.

Then I read the sources and write the piece myself.

The useful part is that I can improve the system by editing the Markdown layer. If the brief overweights vendor claims, I change the source policy. If the output starts sounding generic, I change the voice guide and add examples. If the handoff misses caveats, I update the template. I am not rebuilding an orchestration graph every time my editorial process gets sharper.

The same pattern applies outside writing. For a smart home site like motherhome.io, Markdown workflows can define how to research a new device, which sources matter, how to compare Matter support, and what claims need caveats before publication. For Auth0-related technical work, Markdown can hold SDK references, implementation patterns, documentation paths, and examples of correct integration. For home automation, Markdown can describe what actions are safe, which commands require approval, and what the agent should never infer.

The domains are different, but the architecture is the same: the harness provides capabilities; Markdown carries the domain behavior.

A project might look like this:

ai-app/
├── AGENTS.md                    # Root router and shared agent policy
├── CLAUDE.md                    # Compatibility shim: import AGENTS.md
├── agent/
│   ├── instructions.md           # Runtime-specific always-on prompt
│   ├── skills/
│   │   ├── support-triage.md      # Procedure loaded when needed
│   │   ├── research-brief.md
│   │   └── release-note.md
│   └── tools/                    # Code: typed capabilities and integrations
├── profile/
│   ├── product.md                # What the product is and who it serves
│   ├── domain.md                 # Vocabulary, assumptions, edge cases
│   └── voice.md                  # Tone, naming, UX copy, audience
├── workflows/
│   ├── bugfix.md                 # How this team investigates and fixes bugs
│   ├── content-update.md         # How content gets researched and edited
│   ├── customer-escalation.md     # When to escalate, pause, or ask
│   └── deploy.md                 # Deployment workflow and human gates
├── policies/
│   ├── source-policy.md          # What counts as evidence
│   ├── tool-boundaries.md        # Which actions are allowed or dangerous
│   └── data-handling.md          # Privacy, retention, customer data rules
├── templates/
│   ├── pr-description.md         # Output contract for PRs
│   ├── handoff.md                # Output contract for human review
│   └── decision-record.md
├── examples/
│   ├── good-output.md            # Local taste, with reasons
│   └── bad-output.md             # Failure modes to avoid
└── evals/
    ├── cases.md                  # Scenarios the AI layer must handle
    └── rubric.md                 # What good behavior means

The folder names are less important than the separation of concerns. AGENTS.md should be a router, not a dumping ground. It should tell the agent what kind of project this is, which workflows exist, when to load them, what actions require approval, and where the source of truth lives. If a vendor-specific file is required, make it a compatibility file. My preference is that AGENTS.md becomes the boring root standard, with CLAUDE.md or instructions.md pointing back to it when possible.

The workflows should encode judgment, not only steps. A useful workflow tells the agent when to research, what evidence counts, when to stop, what output shape to produce, and what review must happen before the work is treated as done. Templates turn those outputs into contracts. Examples give the system taste. Policies and evals make expectations inspectable.

That is the application layer I think many AI products are missing. They have models. They have tools. They have framework code. They do not yet have a maintainable place where the team’s judgment about the work can live.

Share The Long Commit

The Part Teams Cannot Skip

Markdown can also make a weak process look official. A stale AGENTS.md is worse than no AGENTS.md if the agent trusts it. A source policy that says “use reliable sources” is not a source policy. A workflow file full of vague advice is not a workflow. A compatibility file that quietly diverges from the real instructions creates another source of truth. A prompt that asks the model not to do something dangerous is not a substitute for a permission boundary.

Instruction files do not automatically improve agent output either. The June 2026 paper “Toward Instructions-as-Code”studied 15,549 agentic pull requests across 148 projects and found mixed results after instruction files were added. Some projects improved; others worsened. That is exactly the kind of result I would expect. The presence of a Markdown file does not prove the team has designed a good AI layer. It only proves there is now a place where good or bad instructions can affect the system.

This is why engineering ownership matters. If a Markdown file changes how the AI product behaves, then changing that file is a product change. It should have owners. It should be reviewed. It should have examples. The important workflows should have eval cases. Stale instructions should be deleted. Vendor-specific files should not multiply into five slightly different policies because every tool wants its own filename.

The future I am arguing for is simpler, not looser. It has less orchestration code for things that should have been written procedure, and stronger code around the parts that need enforcement. It gives domain owners a real way to improve behavior without pretending that prose can replace permissions, tests, or production controls.

The transition from code to Markdown is not a retreat from engineering. It is engineering putting the right work in the right layer.

If I were leading an AI product team, I would ask one practical question before adding another framework node: is this a capability the system must enforce, or is this behavior the harness needs to understand? If it is enforcement, write code. If it is behavior, policy, examples, or handoff, start by designing the Markdown layer.

That is the architecture I would bet on: code for capabilities and constraints; Markdown for the operating behavior the harness can execute.

Production usually tells the longer version. The review queue gets heavier. The same two senior engineers become the validation layer for a larger volume of plausible patches. Support sees more small changes with surprising edge cases. The team ships more often, but on-call starts to feel more expensive. None of this proves the AI rollout failed. It proves the dashboard stopped too early.

That is the standard I would use for this debate: AI can make code cheaper. It cannot make a weak idea useful, and it cannot make production work free.

The AI productivity conversation is still too comfortable measuring the part of software work that AI makes easiest to see. Lines of code, pull requests, story points, and deployment frequency are all close to production of work. They are not the same as value. A team can generate more code, open more pull requests, ship more frequently, and still leave customers with worse software and engineers with a more fragile system to operate.

I do not care very much whether AI helped a team produce more lines of code. Story points were already a weak proxy before implementation became cheaper. Deployment frequency is useful as a delivery capability signal, but it is not a product outcome. Even feature count can lie if the team is shipping work customers do not need. The harsher question is whether the team shipped something that made sense for users and whether the delivery system absorbed the change without pushing hidden cost into review, incidents, support, security, or maintenance.

If the answer is no, the team did not become more productive. It found a “cheaper” way to create activity.

The old cost was a filter

Dax Raad, who created OpenCode, made a useful version of this argument in a February 2026 post that Business Insider covered. His point was not that AI coding tools are useless. It was that code production was often not the real constraint. In one sharp line, he wrote that “ideas being expensive to implement was actually helping.”

That is uncomfortable because it names something engineering organizations do not like to admit. Implementation cost was a filter. Not a fair filter, not always a good filter, and often a frustrating one. But it forced some ideas to die before they became roadmap commitments, support obligations, security surfaces, and half-owned production behavior.

When implementation gets cheaper, weak ideas can travel farther before anyone feels the cost. The organization can build more experiments, more variants, more internal tools, more half-promised features, and more code that nobody is quite ready to own. Some of that is good. AI should make useful neglected work cheaper: tests, documentation, migrations, cleanup, internal tooling, and prototypes that were not worth a full planning cycle. But lower implementation cost also lowers the friction that used to make teams ask whether the idea deserved implementation at all.

The bill does not disappear. It moves downstream.

A shallow AI rollout makes code generation faster and then asks the same review, testing, security, release, and support systems to absorb the extra work. That is where the cost shows up: not when the patch compiles, and not when the dashboard celebrates a larger pile of merged changes, but when the organization has to review, ship, operate, recover from, and maintain the work it just made easier to produce.

Harness has a timely but imperfect signal here. Its 2026 State of DevOps Modernization report is vendor research, so I would not treat it as neutral proof. Still, the pattern is worth attention. Harness surveyed 700 engineering practitioners and managers in large enterprises in February 2026. Very frequent AI coding users were more likely to report daily or faster deployments: 45%, compared with 15% of occasional AI coding users. But 69% of that same very-frequent group said AI-generated code leads to deployment problems at least half the time. The report also found higher reported rollback, hotfix, or customer-impacting incident rates among very frequent users, and longer mean time to recovery for production incidents related to code deployments.

Harness explicitly says there is no causal proof that AI coding caused those problems. That caveat matters. The teams using AI heavily may already be under more delivery pressure, may already deploy more often, or may already have weaker delivery systems. But the caveat does not rescue the easy productivity story. If AI is adopted inside a system that cannot absorb more change, local coding speed becomes a stress multiplier. A good tool can still be deployed into an unready system.

Stack Overflow’s May 27, 2026 pulse survey points in the same direction from a different angle. Among 1,100 respondents, workplace agent use had risen to 59%, but 63% said they rarely or never let agents run entirely on autopilot. Accuracy and security remained the top concerns. This is not an argument that agents have failed. It is evidence that serious teams still treat production AI work as supervised work.

Google’s 2025 DORA AI-assisted software development report uses the right frame: successful AI adoption is a systems problem, not a tools problem. The report also says value stream management should help local productivity gains turn into product performance instead of downstream chaos. That is the sentence I would put on the wall before any AI productivity review. DORA metrics can tell you whether the delivery system is getting healthier or sicker. They cannot tell you whether the thing you shipped should exist. They are guardrails for delivery health, not proof of product value.

Subscribe now

The new work is supervision

The bottleneck does not only move. The work changes shape.

A May 2026 longitudinal study of professional software engineers found that AI coding assistants shifted work away from creation and toward verification. Participants reported spending less time on most development tasks, including 82% who reported spending less time writing code. The authors call the new category “supervisory engineering work”: directing, evaluating, and correcting AI output. They also found a productivity-experience paradox. Self-reported productivity improvements stayed high, but among matched participants, the share reporting worse developer experience in at least one dimension nearly doubled from 14% to 27%.

That matches the texture many senior engineers recognize. AI does not remove judgment. It moves judgment to a different place and then sends more material to that place.

Code review is where this becomes obvious. A 2026 vision paper on code review in the age of AI argues that AI coding assistants increase code production velocity while expanding the volume of code requiring review, turning review into a growing bottleneck unless the workflow around it changes. The paper is a research agenda rather than an outcome study, so I would not cite it as proof that every team is seeing this. But the direction is right. If the organization makes code cheaper and keeps review mostly manual, review becomes the place where the productivity story has to pay rent.

That is especially true for senior engineers. A team can celebrate more output while concentrating more validation work on the people least able to absorb it. Those engineers already carry architectural memory, production intuition, incident scar tissue, and the informal taste that keeps a codebase from turning into a pile of plausible patches. If AI increases the amount of code that needs their judgment, the organization may be spending its rarest capacity faster than before.

Siddhant Khare, who builds agent infrastructure, described the human version of this shift in his February 2026 essay on AI fatigue: “AI reduces the cost of production but increases the cost of coordination, review, and decision-making.” That is the part most productivity dashboards miss. The code may arrive faster, but the decisions around the code do not become free. Someone still has to decide whether the output is correct, safe, maintainable, aligned with the architecture, worth shipping, and worth owning.

This is why I distrust most AI productivity metrics. They usually stop counting at the point where AI looks best.

Measure past the merge

The mistake is stopping measurement where AI looks best. The useful question is what the system has to absorb after the code exists.

Lines of code, pull request counts, story points, and even cycle time can create the appearance of progress while missing the harder question: did customers get better software, and did the delivery system stay healthy? If cycle time improves because reviews get thinner, tests get weaker, or teams ship work users do not care about, the metric did its job poorly. It measured motion and missed value.

Harness’s 2026 State of Engineering Excellence report makes this measurement problem explicit, again with the same vendor-evidence caveat. Its survey says 81% of engineering leaders report increased code review time since deploying AI, 31% of a developer’s day is now consumed by AI-related invisible work, and 94% say technical debt, validation time, and developer burnout are missing from current metrics. I would not build a strategy from those exact numbers. I would take the pattern seriously: organizations are measuring output more readily than they are measuring the effort required to make that output safe and useful.

METR’s February 2026 update on developer productivity measurement is useful for the same reason. METR’s earlier randomized study found that experienced open-source developers were slower with early-2025 AI tools, but its 2026 update says the next experiment design became hard to interpret as AI adoption changed participation, task selection, quality choices, and time reporting. Developers selected different tasks when AI was allowed, changed how much documentation or testing they produced, and sometimes worked on other things while agents ran. That does not make measurement hopeless. It means the simple before-and-after story is often the least trustworthy story.

The measurement boundary has to move downstream, toward the places where software work becomes value or turns into debt. I would want a downstream ledger with five categories.

• Customer value: adoption, task completion, retention, revenue, support contacts, or whatever signal maps to the user’s life getting better.

• Delivery health: lead time, change failure rate, rollback rate, mean time to recovery, flaky pipeline pain, and release interruptions.

• Review quality: pull request size, review queue time, review rounds, senior reviewer concentration, and whether reviewers are being asked to validate code the author does not understand.

• Maintenance cost: rework, follow-up fixes, documentation drift, dead features, duplicate code, and code that becomes hard to change a month later.

• Human cost: cognitive load, on-call interruption, after-hours recovery, and whether the best engineers are spending more time supervising output than making hard technical decisions.

The exact metrics depend on the team. The principle does not: do not let the measurement stop at the point where AI looks best.

Subscribe now

Roll it out as a production change

If I were accountable for an engineering organization adopting AI coding tools, I would not frame the rollout as “make engineers faster.” That framing points everyone at the part of the system the tool can most easily accelerate, then acts surprised when the rest of the system starts to strain. I would frame it as a delivery and product quality change.

For production work, the author still owns the change. I do not care whether the code came from a model, a snippet, a Stack Overflow answer, a generated patch, or a late-night burst of human confidence. The person merging it is responsible for understanding it. “The AI wrote it” is not a root cause. It is a sign that ownership got blurry.

I would also make the risk boundaries explicit. AI-generated tests, documentation, migrations, internal tools, and boilerplate can often move faster with lower risk. Code touching authentication, authorization, payments, data migration, concurrency, incident recovery, privacy, or customer-visible behavior should not get a lighter review because a model produced it. In some cases it deserves a heavier review, because plausible code can be harder to distrust than obviously messy code.

I would protect review capacity before celebrating output. If AI increases pull request volume, the answer is not to tell senior engineers to review faster. Shrink the changes. Require authors to explain generated code before review. Track review queue time. Give reviewers room to do the work. Make it acceptable to reject a generated patch because the author cannot explain the tradeoffs. A review culture that depends on two overloaded senior engineers was already fragile. AI just makes the fragility harder to hide.

I would measure the rollout at the team and system level, not as individual surveillance. The goal is not to rank engineers by prompt efficiency, AI acceptance rate, or commits touched by a model. That will teach people to game the tool and hide the work. The goal is to learn whether the team is delivering more customer value with equal or better production health, review quality, maintenance cost, and human sustainability.

That is a higher bar than “we shipped more code.” It is also the only bar that matters.

The useful counterargument

Some teams really are shipping more value with AI. The piece should not pretend every AI gain is fake. AI can make neglected work cheaper: tests, documentation, migrations, internal tools, API exploration, cleanup, and the boring tasks that used to lose every prioritization fight. For teams with strong product judgment, review discipline, and ownership norms, those gains can turn into better software and less operational pain.

But that does not weaken the argument. It raises the standard of proof.

If AI helps your team ship a feature customers use, with the same or better reliability, without overloading review, without hiding maintenance cost, and without turning senior engineers into cleanup infrastructure, then call it productivity. That is the kind of win I would take seriously. If AI mostly increases the number of things in motion, the number of pull requests waiting for review, the number of features nobody asked for, or the amount of code nobody fully understands, then the team has not discovered leverage. It has discovered a cheaper way to create inventory.

Software teams already had too much inventory: backlogs full of maybe-work, roadmaps full of stakeholder theater, codebases full of half-owned decisions, and dashboards full of metrics that make motion look like value. AI does not forgive those habits. It compounds them.

Users pay the invoice

The title says the bill comes due in production, and that is true. Production is where weak assumptions stop being private. It is where review gaps, unclear ownership, fragile rollouts, missing tests, and confused product decisions become visible.

But production is not the final customer. Users are.

A production system can survive a change that still should not have been built. A team can deploy safely while wasting months on features that do not improve the product. AI productivity measured only at the engineering boundary will miss that failure.

The sharp version of the claim is this: AI productivity that does not reach users as better software is not productivity. It is cheaper throughput inside the factory.

That does not make AI bad, and it does not mean teams should avoid the tools. Teams should use them and push them hard. Let engineers automate the boring parts. Let agents draft, test, explain, migrate, and explore. But do not let the organization pretend that faster code is the same as better software.

The bill comes due in production, but the invoice is paid by customers. If they do not get a better product, and the team does not get a healthier delivery system, the productivity story is just a nicer dashboard wrapped around more work.