This newsletter is sponsored by Hygraph.

[Webinar] AI content workflows that actually save you time

Connecting your CMS to Claude via MCP sounds simple. Scaling it into workflows that actually increase your content output without adding headcount is the hard part.

More prompts and larger context windows give AI access to your content, but not the structure to use it well. Teams pulling ahead fix that through their content model, so output comes back accurate and publish-ready.

Join live on Sep 30 (FREE) to learn from the content workflows that:

• Generate 750+ pieces of GEO content without slowing the editorial calendar

• Save 20-30 minutes per blog post, no new hires needed

• Split one workflow into 5 pipelines instead of one blowing up the context window

If you’re trying to get more from AI without adding headcount, this one is worth your time.

Register now

Thanks to Hygraph for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I used to believe that as a leader, I needed to know everything. When I first grew from a senior software engineer to a team lead, leading a team of 5 people, I tried to take on the hardest tasks, finish the most tasks, have everything under control, and also work on weekends.

The team felt like I was trying to do everything myself and didn’t trust anyone around me. Well, that got me quite close to burning out, and I was forced to make a change.

I made a deliberate change to start delegating more and empowering and trusting my team. Things turned out a lot better after that.

As a leader, you are not judged by your individual contributions but by the success of your team and projects. So, remember that making others around you better is your number-one goal.

Now that we understand what’s really important, we’ll go over 6 actions you can take to become an engineering leader everyone wants to work with.

This is an article for paid subscribers, and here is the full index:

- Be a Team Player
- Take a step back from individual work and look at the big picture
- Regularly check in with your teammates
- Learn and grow together as a team
- Manage Up, Down, and Sideways
🔒 Create a Positive Work Environment
🔒 Don’t Blame
🔒 Coach and Mentor
🔒 Empower and Uplift Your Team
🔒 Last words

Let’s start with the first one!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published in mid-to-late October this year.

Learn more about the book

Be a Team Player

It’s really important to make the mindset shift as an engineering leader and transform the way you think. It should be a lot less “I” (“I did this.”) and a lot more “we” (“We as a team did this.”).

In software development, it’s really all about the team, the projects we’re working on, and the goals we’re trying to achieve. And one of the best ways you can be a team player is to put your team’s success first.

Here are some actionable tips that will make you a team player as a leader.

Take a step back from individual work and look at the big picture

Ask yourself the following questions every day to determine what you can do to help your team:

• Is there someone who’s stuck and needs help?

• Does the team have everything they need to be successful?

• Is a senior leader asking for something important?

Regularly check in with your teammates

You can check in with them through 1:1 meetings or quick chats at the start of team meetings. See how they’re doing, both in their work and personally.

Did someone just come back from a trip? Ask about it. On Monday mornings, ask how their weekend was. These small moments of connection go a long way toward building trust and supporting your team.

And when your teammates feel supported, the whole team performs better.

Learn and grow together as a team

You want to avoid creating or perpetuating knowledge silos, in which only one person knows how to do something. As a leader, create opportunities for knowledge sharing.

Use meetings, Slack, or other channels to encourage people to share what they’ve learned. If someone discovers something new, have them explain it briefly and share what new they have learned.

That way, everyone will benefit and the whole team will get stronger together.

Work on your own teamwork skills

If you’re not already a team-oriented person by nature, it’s a good idea to consciously develop teamwork as a skill.

If you’re not sure how to do this, I recommend finding a hobby or activity outside work in which you collaborate or work with a group to achieve a goal.

This could be playing sports (or video games or board games), working on a side project, taking part in a community, or something else.

Manage Up, Down, and Sideways

To be considered a great engineering leader to work with, you need to manage up well (to your manager, leadership, and stakeholders), down (to your team) and sideways (to your peers).

If you mishandle one part and don’t build a decent working relationship, the other parts may suffer.

A mistake I made as a new team lead and later as an engineering manager was shielding my team too much and trying to sugarcoat things when we were having major issues.

Instead, I should have involved the team earlier, looked to collectively address things, and not tried to solve the major issues on my own.

I also made a lot of other mistakes, like the ones I mentioned in the article: How to Manage Up as an Engineer or a Manager: sending an email about potential improvements to my skip-level manager while not trusting my direct manager to handle those improvements, plus expected my new manager to change their working style because I was used to the working style of my previous manager.

All of that really doesn’t work, and I just ended up making our working relationship worse. So how can you manage successfully in all directions?

My top 3 tips are as follows:

• Build good relationships and good communication practices.

• Try to proactively find out the problems that people around you are facing and put in the effort to resolve them.

• Be transparent, give feedback, and ask for help when you need it.

Create a Positive Work Environment

Read more

This newsletter is sponsored by Unblocked.

[Webinar] How to stop babysitting your agents

Agents can generate code. Getting it right for your system, team conventions, and past decisions is the hard part. You end up wasting time and tokens in the correction loops.

More MCPs, rules, and bigger context windows give agents access to information, but not understanding. The teams pulling ahead have a context layer to give agents exactly what they need for the task at hand.

Join live on Sep 23 (FREE) to see:

• Where teams get stuck on the AI maturity curve and why common fixes fall short

• How a context layer solves for quality, efficiency, and cost

• Live demo: the same coding task with and without a context layer

If you want to maximize the value you get from AI agents, this one is worth your time.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

It’s important to realize that a lot of the problems teams face today are not new. We’ve been struggling with coordination, missing deadlines, bad metrics, adopting “shiny new technologies” for quite a while now.

That’s why understanding the laws like Conway’s Law, Brooks’s Law, Goodhart’s Law, Hofstadter’s Law, Amdahl’s Law, and Amara’s Law are so important and truly timeless.

And what’s important to mention is that in today’s AI era, many of them are becoming even more relevant. With the speed of building increasing, the bigger bottleneck becomes coordination, communication, and good leadership.

In today’s article, Dr Milan Milanovic will be sharing the most important laws you need to know for leading engineering teams. He’ll also be sharing examples of these laws from his personal experience.

Let’s introduce our guest author and get started.

Introducing Dr Milan Milanovic

Milan is a CTO, Microsoft MVP, and also an author of the book Laws of Software Engineering. He has more than 20 years of experience both as an engineer and engineering leader, working across many different industries.

I know Milan for quite a while now, and we chat occasionally on various topics. Today, he’s been kind enough to share some of the important insights from the book adapted for this article.

Over to you, Milan!

Understanding the specific software engineering laws is crucial for leading engineering teams

Throughout my 20-year career in tech, especially working at big companies and on large projects and teams, I noticed some specific patterns. Back then, still a young engineer, I couldn’t define them well.

Later, when I worked on some other projects and in new companies, I noticed the same patterns again. It became obvious to me that the same mistakes happen in almost every company.

This was the first time I researched a bit more about them, and it was immediately obvious that they are not new and some are old, like 20 or 30 years or more (Brooks 1975 and Conway 1967).

What also surprised me was that most of my colleagues back then didn’t know about them.

The second time I came across them was when I was writing an article on why engineering teams’ estimations and plans fail. It became obvious that a lot of these laws play a big role and are crucial for success of engineering teams.

So, my recommendation if you want to lead a high-performing engineering team, is that it’s really important that you know and understand the laws I am going to share today.

What’s also important to mention is that, with the emergence of AI in the last few years, a lot of these laws are even more important than before because we have shorter cycles, smaller teams, and a lot of these laws can be violated much faster.

Let me start with the first law!

1. Conway’s Law

This one is probably the most well-known of all laws, and it can be harder to grasp and understand, especially if you’re just starting in the industry.

It says that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

Let me share an example.

If we have small distributed teams of a few engineers working in different places, the architecture of the system will probably be Microservices. Why? Because it reflects the organizational and communication structure of the team. On the other hand, if we create one large team, we will probably have one big monolith.

I remember once working on a big banking project with a large team; the system was one big monolith, and it was really hard to maintain.

Then we sat down and created a new organizational structure with subteams, and split our monolith into modules, so it became a modular monolith.

Each subteam became the owner of one module. It was not possible to split the architecture into modules before reorganizing teams first.

It’s important to note that we should not copy someone else’s structure, e.g., the Spotify model, because this model solved their coordination problem, not ours.

2. Brooks’s Law

This one is also very important for leading engineering teams, and the reason is that we are often in a situation where our projects are late.

There are a few things we can do in this situation, and I’m sure that every leader has tried to solve this problem by adding more people to the team (or teams).

This is exactly what Brooks’s Law warns us about which states that adding more people to a late project only makes it later.

It looks a bit contradictory at first glance, but if we think a bit more about it, it is not. When we add more people to the late project, we do 2 things:

1. We increase the number of communication and coordination channels in the team.

2. And we take time from the existing team members to do their job, because they need to take part of their time to work and onboard new people.

The math is simple, e.g., with 8 people in the team, we have 28 communication paths, while if we have 6 people in the team, we have 15.

Let me share an example from my experience next.

In one of our projects, we had 8 team members, and we were always late for our deadlines. We tried different things, such as making estimations with buffers, hiring new people, etc. But we always ended up being late on our commitments.

What happened after was that 2 people left our team, and all of a sudden things became more efficient, and we managed to deliver on our commitments.

This was surprising, but as communication paths dropped from 28 to 15, obviously this had an impact.

What I found is that there is also a way to measure this, and is called Little’s Law, which comes from queuing theory.

Little’s Law (L = λ * W) refers to work in progress, throughput and lead time. For example, If your team completes 5 tasks per week and you have 20 in progress, the average lead time is 4 weeks. Increase WIP to 40 with same throughput, lead time is 2x now.

So when you add people to a late project WIP goes up and throughput stays flat. The outcome? Longer lead times, not shorter. Reduce work in progress (WIP) before adding people if you want to get things done faster.

3. Goodhart’s Law

This one is probably the most relevant for managers and leaders. And it’s becoming even more important due to AI.

This law states that when a measure becomes a target, it stops being a good measure.

Many companies make a mistake where they measure certain metrics and treat their direct outputs as goals.

Some examples of this are:

• lines of code written,

• test coverage percentage,

• tickets closed, etc.

The main problem with this approach is that when we attach our goals to outputs, people will find a way to gamify these metrics and become good at increasing them, while not actually increasing business value.

I remember when, in my early days, our manager considered better engineers those who produced more code, although we knew this was not true.

Once, one of our best colleagues decided to remove 1,500 lines of code and simplify one of our modules in payroll. The system became simpler and faster, yet our manager rated that as an example of a not-good job.

Now, with AI, we see similar trends with spending AI tokens (tokenmaxxing). Engineers who spend more tokens are considered more valuable, and some companies even created leaderboards for that.

So, how to solve this problem? Focus on outcomes, not outputs. Define metrics, but use them only as proxies, not targets or rewards.

The focus should be on producing meaningful results. Here is an example:

The metric “Cycle time” alone just tells us that something is moving, but cycle time + what we shipped this month, and whether it provided value for the users, tell us a more complete story.

In our team, we saw a good example of this when we decided to move from Scrum to Kanban and completely remove story points and estimations.

Before, we always tried to achieve our velocity and measured everything by it, yet we spent a massive amount of time on estimations, discussions, etc.

When we removed them, our team became much more efficient, and we could produce more value for our users.

Sidenote: The Bus Factor

The Bus Factor states the minimum number of team members whose loss would put the project in serious trouble.

A bus factor of 1 means one person holds critical knowledge; if they disappear, the project is essentially ‘doomed’ or stalled. A higher bus factor (e.g., 5) means the project could lose any one of 5 specific people before stopping work.

It’s basically a measure of knowledge distribution and risk. A high bus factor is good (knowledge is shared among many), while a low is bad (single points of failure in expertise).

Teams should work to increase their bus factor by sharing knowledge, documenting critical systems, having code reviews, and rotating responsibilities.

Let me share an example from my experience. Once, we had an engineer on our team who was the only one who knew our billing system, and he was preparing for a long vacation.

This was Bus Factor 1, and it’s very problematic. We decided to pair him with another person who would take over some important parts of the system, moving Bus Factor from 1 to 2, and he was no longer a single point of failure.

The question we should always ask for every member of our team is: If person X leaves us tomorrow, can we still operate? If no, then there needs to be more exchange of knowledge.

4. Hofstadter’s Law

As we worked in Scrum for years, we had all the regular estimation sessions. After some time, we figured out that we actually missed each of the deadlines we set.

We knew this, and we tried everything we could to improve, but still deadlines were mostly missed.

This was exactly what Hofstadter’s Law defines: it always takes longer than you expect, even when you account for Hofstadter’s Law.

And when we tried to analyze this (didn’t know about the law then), we figured out that there are many moving parts in our work. API integrations depend on someone else; one engineer got sick, some of our designs didn’t match reality, and more.

Also, there is something called the Ninety-Ninety rule, which says that the first 90% of the project takes 90% of the time, and the last 10% takes the other 90%, and this is true.

When engineers think about the project, they mostly think about the first 90%, and this is actually the core of the implementation, e.g., business rules.

But the last 10% could take the same amount of time, as they didn’t account for integration delays, authentication, edge cases, and more.

Taking all of this into account, I have a few simple rules to follow. First, if I need to estimate some work, I say:

• If it takes 2 min, do it immediately

• If it takes a “few minutes”, estimate it at an hour

• If it takes a “few hours”, estimate it as a day.

Another important thing is communication with stakeholders. We need to be open and honest with them, and what this means is that we don’t accept any roadmaps longer than a quarter to give any kind of estimate.

And for all the estimations, we should always add buffers to cover the Ninenty-Ninety rule.

Here we need to mention also Parkinson’s Law, because it says that work will expand to fill all the time available for it. So, if we can finish something in a day, but we estimated 3 days, it will probably take the full 3 days to finish.

I was on teams where estimations took more time than the implementation itself. So, we as leaders need to take both laws into account when working on projects. It is always better to have short deadlines with clear objectives than longer ones.

5. Amdhal’s Law

This law defines why AI productivity is not the same for everyone. For example, if half of our workflow is sequential, the maximum we can get from speedup is 2x.

If that workflow is 90% parallel, then we can get a 10x improvement.

The main thing here is that often we think that Software Development Life Cycle (SDLC) = coding, but it is not.

It includes many other parts of the job we need to do, such as deciding what to build and how, communication with the product team, reviewing code, waiting for different kinds of approvals, and more.

Coding is now much faster, but the other parts stayed the same. What I found is that teams that were able to increase their productivity more are those that made the human-in-the-loop part smaller.

It is the same on the organizational level as well. If we have an ivory architect or a CTO who needs to approve every decision, adding more resources to the project will not speed it up; you will just get a longer queue.

So, in order to improve your processes first measure the sequential part, because only adding more resources to the parallel part will not do miracles.

6. Amara’s Law

This law is also known as the Hype Cycle and is something we have seen for decades in tech.

We tend to overestimate the effect of technology in the short term and underestimate it in the long term.

We saw this starting in the 1960s and 1970s when work on AI systems started; it promised general intelligence, but the results were modest.

We also had a few long AI winter periods. In the meantime, research continued to work on AI (e.g., Prof. Hinton and his work on neural networks when everyone thought it is a dead end), and now, with all the tools from the past few years, we have seen remarkable changes in our industry.

Usually, the loudest voices are those who don’t use technology so much. So, the short-term promise was not true, while the long-term promise is something we could not imagine.

The same thing we had with Microservices. It was marketed as a one-size-fits-all solution for any scaling problem, but then we had many replicated projects that had more services than users.

I remember seeing only microservices architecture on many projects I worked on, often asking myself if it was really needed. In most cases, it was not.

For leaders, it is important not only to be right with decisions, but to be right at the right time too. If we miss the timing, then it is the wrong decision.

If we adopt it at the top too early, this could cost us later when everything changes (this is actually a Dunning-Kruger effect).

If we completely fail to adopt it, then we are late to adopt something everyone is already using.

What we should do is to treat innovation as a budget. Most of our track stays on proven technology (see Lindy Effect after), while we take small tries on hyped things. If it proves successful, then we expand it; if not, remove it.

Sidenote: The Lindy Effect

Together with the Hype Cycle, we should mention the Lindy effect, which says that the longer something is in use, the longer it will stay in use.

E.g., take an example of SQL from the 1970s or COBOL, which is used in half of the world’s banking transactions. On the other hand, we have all seen many libraries and frameworks that are not used anymore.

So, our main selection should be around the things that are proven and have been around for many years. AI changed one thing, and that is that it is much easier to replace certain legacy software.

A big COBOL codebase was not touched because no one fully understood it. Now, with agents, it’s much easier to do so. Yet, the fundamentals like algorithms, system design, architecture, and data structures are still very crucial.

So, now we should not ask anymore how long this technology will be with us, but whether it is the best way to solve the problem, and if AI can more efficiently replace it.

For me, I invest in things that AI cannot easily replace, such as fundamentals and judgement.

Using the laws together

We should know that no problem involves only one law, but usually a few of them. If our delivery is slow, there are 2 or 3 laws impacting this. The wrong turn would be to fix it before we know which ones exactly.

This is a checklist I run when I have an issue in a team:

1. Conway’s Law

Does our team structure match the system? If this is not true, we are probably losing too much time in coordination activities.

2. Brooks’s Law

Did we add any new people recently? If yes, then this could lead to a stall in the project.

3. The Ringelmann Effect

If our teams have 8 or 9 people or more, the output for each of them will probably drop.

4. Goodhart’s Law

If the team meets goals but our product is not better, nor are users satisfied, then the metric has become the target.

5. Broken windows theory and Tech Debt

This one is usually forgotten. If the codebase is in the state where no one bothers to fix issues, then this is a big problem. Even with AI, this doesn’t improve.

So, to conclude, we don’t need to know all the laws. If we have an issue with our team, we should do the following: 1) name the forces, then 2) rank them by importance. If you have a deadline, Hofstadter is more important than Amdalh.

Also note that in some cases, there are different laws that contradict each other; e.g., Brooks’s Law and Linus’s Law are both true, but in different contexts.

Last words

Special thanks to Milan for all the insights with us! Check him out on LinkedIn, and also check out his book Laws of Software Engineering to get to know all the important laws in software engineering.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

This newsletter is sponsored by Nango.

Connect your products & agents to 1,000+ APIs

Nango offers everything you need to connect your AI agent with external APIs:

• Pre-configured integrations for 1,000+ APIs with 7,000+ tools: let your agents securely discover & call tools across 1,000+ APIs without clogging context.

• Every integration type covered: auth, tool calls (MCP-ready), triggers, and syncs, with token refresh, rate limits, retries, and logs handled for you.

• Extensible and enterprise-ready: customize any integration in code; supports SOC 2 Type II, HIPAA, RBAC, audit trails, BYOC, or self-hosting.

Open source with 11.7k+ GitHub stars, used in production by Smartsheet, Ramp, and ServiceNow. Simple pay-as-you-go pricing.

Try Nango for free

Thanks to Nango for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

You may believe that people will see you as reliable if you do good work. But there’s a lot more to it, and you need to be intentional about how you showcase your reliability.

What seems reliable to you might not seem reliable to your manager or stakeholders, so try to see yourself from their perspective.

In this article, we’ll break down all of the things you should do to be seen as a reliable person who gets stuff done.

This is an article for paid subscribers, and here is the full index:

- Do exactly what you agree to do
- A lot of your success is determined by how well you communicate
- Provide estimates instead of making guesses
- Keep your manager in the loop
- Admit your mistakes
🔒 Get good at time management
🔒 Prioritize ruthlessly
🔒 Block out focus time
🔒 Have separate maker time and manager time
🔒 Use Pomodoro to avoid distractions
🔒 Improve communication to save time
🔒 Cancel pointless meetings
🔒 Say no more often
🔒 Take time off
🔒 Last words

Let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published in mid-to-late October this year.

Learn more about the book

Do exactly what you agree to do

During one of my very first freelance projects, I was working hard to build a website for a client. But my communication wasn’t really on point.

I wasn’t asking questions to find out what was really needed, and I wasn’t managing the client’s expectations the right way. I was just focused on building.

To my surprise, what I delivered wasn’t what the client expected. It went too far in a different direction, and the client immediately saw me as less reliable.

I was able to turn the project around by making appropriate adjustments, but my reputation was already damaged. The client didn’t send me any more work after that.

So I learned this lesson the hard way:

You can do the best work in the world, but if you don’t manage stakeholders’ expectations and deliver what they’re relying on you for, it won’t mean much.

After that, I started regularly updating my clients on my progress, asking the right questions, sending previews, and asking for confirmations before I started building.

Being reliable got me more projects than I could handle. I learned that continuous communication works much better than “big-bang” reveals. Clients don’t want to be surprised. This is true for full-time roles as well.

A lot of your success is determined by how well you communicate

Notice that a lot of what we mentioned above takes place before the work actually starts:

Doing great work starts with being careful and precise about what you agree to do (and when and how you agree to do it).

Additionally, look for ways to narrow the scope of the project or a task in order to deliver on time. It also helps to give two options and let the stakeholder of the project choose as well.

An example of a trade-off in order to finish the project on time:

“We found out that to finish X completely, we also need to do Y, which will take 3 to 5 additional days.

I’ve talked with the product manager and, as an alternative, we could adjust the scope of X and deliver without also doing Y.

I suggest we pursue the second option, but please let me know which option you would prefer.”

This clear communication shows that you care about finishing the project on time, have taken ownership, and are proactively searching for a solution.

Provide estimates instead of making guesses

If you’re not exactly sure how long something will take, share a confidence percentage and estimate a range.

I can’t tell you how many times I’ve made the mistake of saying things like “This will take five minutes,” or “This is very easy to do.”

In planning meetings, I used to say that something was very easy to develop and then spend the whole night working on it to prove that it wasn’t that hard.

After making many inaccurate estimates, I learned that it’s much better to not go straight to optimism. If you are not entirely sure, say so and attach a confidence number to it like this:

“With 70% confidence, I estimate that we can finish this within 2 to 3 weeks.”

This sets the expectation that you might be wrong, which in software development is realistic: a lot of things are uncertain and hard to predict.

It won’t be a problem if you’re wrong as long as you communicate as early as possible and don’t make claims you can’t deliver on.

Keep your manager in the loop

Your manager shouldn’t have to ask you for status updates. Be proactive and send the updates yourself. I recommend following this template:

We’re on track to deliver [functionality] by [date]. 
We have completed [recent achievement] and we’re now focused on [next steps].

Risks and roadblocks

[Brief issue summary and mitigation plan

[Brief issue summary and mitigation plan]

What’s next?

[Task or goal: ETA: date-date]

[Task or goal: ETA: date-date]

Support needed [if any]

[Specific ask or decision needed from your manager]

Let me know if you’d like more details!

You can send this update via Slack or email. The important thing is to keep it concise.

Admit your mistakes

If you make a mistake, admit it and learn from it, don’t try to sweep it under the rug. Take ownership and do everything that you can to learn from it and help others to learn from it, so no one else makes the same mistake.

Robert, a student in the course “Senior Engineer to Lead”, suggests sharing what you did that led to the mistake and what you’ll do to avoid the mistake in the future.

Then, share it with your manager and the team. This shows that you’ve taken action to learn from and avoid repeating the mistake and that you care about both quality and learning.

Get good at time management

Read more

This newsletter is sponsored by Unblocked.

[Webinar] How to stop babysitting your agents

Agents can generate code. Getting it right for your system, team conventions, and past decisions is the hard part. You end up wasting time and tokens in the correction loops.

More MCPs, rules, and bigger context windows give agents access to information, but not understanding. The teams pulling ahead have a context layer to give agents exactly what they need for the task at hand.

Join live on Sep 23 (FREE) to see:

• Where teams get stuck on the AI maturity curve and why common fixes fall short

• How a context layer solves for quality, efficiency, and cost

• Live demo: the same coding task with and without a context layer

If you want to maximize the value you get from AI agents, this one is worth your time.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

A scenario that I have heard quite a few times (and it has happened to me as well):

A new engineer gets promoted and becomes a manager for the first time. That new engineer quite quickly discovers that the new role is less about engineering and a lot more about dealing with people.

It’s a hard shift, but crucial to understand, a lot of the work that you need to do as a manager is to know how to deal well with other managers, the leadership team, and also balance that well with your team as well.

That’s where understanding company politics is crucial.

In today’s article, we’re going through all about company politics, and I’ll share my advice for you to deal with it better. I’ve personally made a lot of mistakes and learned a lot about it over the course of 13+ years in the engineering industry.

Let’s start!

The more you grow in your career, the more you’re going to feel company politics

When I first grew from a Senior Engineer to leading a team of 5 engineers as a Team Lead, I got a first sense of what company politics actually looks like.

I was invited to a meeting where every team lead was presenting what new things they and their team had achieved (including my team and me), and then all of a sudden the executives on the call started shouting at each other and blaming each other for some mistakes.

I can’t remember the exact words, but it was something along these lines:

“Engineering is moving slowly”, “Product is not giving the right requirements”, “Sales is promising something that can’t be delivered”.

I had quite an optimistic view when I first became a Team Lead, and that was what I witnessed that day. I thought that maybe this was an exception, and it’s not what it actually looks like when you grow even further.

But I was definitely wrong. Especially when I later grew to become an Engineering Manager, leading 3 teams, I was exposed to company politics even more.

As an enthusiastic manager, I wanted to make things better across the whole company, even the areas outside of my control. What I quickly found out is that the best solution doesn’t always win.

There’s a lot more to it. I tried to make the process better, I tried to make the way we are handling certain meetings better, etc. But it has often ended up in a dead end. The responsible person for a certain area normally said they’d look into it, but nothing really changed.

In some cases, I was even reported to my manager for trying to “stick my nose into something that’s none of my business”.

So, yes, it’s not about having the best idea, and in some cases, if you want something, people will even do everything in their power to go against it.

What I quickly learned is that good relationships, your reputation, and credibility + being able to influence well, that’s what’s really important in order to manoeuvre company politics well.

Across this article, I’ll be sharing my advice on what I would personally do if I could turn back time, when I didn’t know anything about company politics.

Understand the politics without becoming part of the problem

If I could go back to the time when I first became an Engineering Manager, this would be my first piece of advice for myself. I can’t go back, but maybe some of you, reading this, are in a similar position.

It’s crucial to understand and find out how things work inside the organization you are in, who the person is who has the biggest influence (title doesn’t always provide the biggest influence by default), and who has good relationships with whom.

So, let’s break it down.

First, find out how people (who are your peers or higher) like to work

This is crucial because not every organization operates the same, and some people may be in a certain position for a while, and they have developed certain habits. The worst thing you can do is try to push your whole new process to them and assume they would just be magically happy with it.

Well, if you have a really good reputation and credibility (both internal and external), that might work, but if you don’t, there’s a good chance there’s going to be pushback, and your relationship with them will become worse.

So, especially if you need to collaborate and work with someone on a certain thing, it’s always better to find out what the process is that they are used to.

My recommendation is to talk with your manager, really understand how things work, and also ask for advice on how to approach a certain person. If you have a good relationship with other people inside the company who might know, you can also ask them.

Second, find out what I like to call the “influence diagram”

This is crucial because that’s how you’re going to better understand how decisions get made, and the influence diagram is not always the same as the reporting diagram.

You need to understand who has more influence inside the company and who has less.

That’s how you’re going to know who you need to talk to if you want a certain change to happen. Even better, if you have a good relationship with them.

This is something that you normally “visualize” inside your head, but if you have a hard time doing that, you can also create an actual diagram where you connect the dots on who has a good relationship with who, and which person might have the highest or lowest credibility.

Third, start building good relationships

As I’ve mentioned above, from my experience, making changes and decisions across the whole company is not about having the best idea, but it’s all about relationships and your overall credibility and reputation.

If you make a suggestion to someone who is your peer about a certain change, they will ask themselves 2 questions:

• How risky is it for me to say “Yes”?

• What am I gaining or losing from this change?

And having a good relationship with them automatically de-risks that specific change for them, because they know you already. And even better if you have strong relationships across the whole organization, that specific suggestion sounds a lot less risky.

For building better relationships across the organization, take a read of this article:

Building good relationships is all about giving first and helping them succeed.

Fourth, focus on building your credibility and social proof

This is a prerequisite to everything that you do. If you have good credibility and good social proof, people will automatically be more willing to work with you, and you will have a much better time dealing with company politics.

You’ll be able to build good relationships a lot faster, and people will automatically see a certain new suggestion as “less risky” because of it.

Think of it as the “armor” that you put on yourself that helps you protect yourself from bad things happening to you, and gives you an advantage when you’re dealing with tricky situations.

That’s also one of the main reasons why I highly suggest that every engineering leader devote time to building both. I view it as a part of the job to do that.

Spending your time on building both is going to be a time well spent. What others say about you when you are not in the room matters a lot.

Things like writing online, public speaking, and having a good LinkedIn profile will automatically increase the perspective people have about you. And it’s very important that you leave a good one.

Fifth, try to not take part of unhealthy politics

This one is important because the fact is that you are going to be affected by the company politics, and the way you operate will influence you. But try to distinguish good and bad politics, and avoid the bad one as much as you can.

For example, if people are openly blaming others or saying bad things about certain people openly, don’t automatically fall into that as well.

Or, if a certain leader is sending out emails overnight and on weekends, or even holidays, and always sticking the “urgent” sign to every request, it’s a bad habit for you to try to do the same.

Another one is to be “always online”, because a certain leader is always online to show everyone how much they are working.

It’s really important not to fall into these bad habits, because “that’s just how everyone operates at a certain company”.

Not every company culture is worth keeping up with it

I’ve been a part of some good cultures and some really toxic ones as well, where company politics were very unhealthy, and looking back at them, I should’ve made the move to go elsewhere sooner.

But interestingly, I somehow hoped that things would get magically better. But in reality, they never do.

Company politics rarely change unless there is a drastic change in leadership, starting with the CEO (in some cases also investors who are a lot more hands-on).

So, always ask yourself this question: “Is this environment healthy for me to be a part of long-term or not?” This will give you a good answer, and if the answer is “No”, that’s the time to start looking elsewhere and see what options are out there for you.

But also keep in mind the following: Every company has pros and cons, and the grass is not always greener on the other side. So, moving to another company might not actually solve your problem.

Even if the interviews are great and the experience talking with different people has been good, you really see the actual culture when you join the company.

That’s also why my recommendation to you should be to have career and job optionality. I know it’s a lot harder these days, especially in the engineering industry, but with enough credibility and social proof, you can have that.

You just need to keep working on it every day. You got this!

Last words

Always keep in mind that “dealing with company politics” and being able to deal with it well is actually part of your job as an engineering leader, there’s just not any official requirement for you to do that.

I’d even say that a lot of your success in your role depends on how well you are able to deal with it, so treat it as an actual skill and focus on improving it.

It will pay dividends in the future, I promise.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

This newsletter is sponsored by DX.

Live webinar: Introducing the CAFE(S) framework for improving AI agent effectiveness

As AI agents become more capable, context quality is increasingly the limiting factor in their performance.

Join leading researchers on September 24 for an early look at CAFE(S), a new framework for evaluating whether AI agents have the context they need to do their jobs well.

The webinar will cover:

• A practical framework to evaluate the five core dimensions of AI agent context quality.

• A shared vocabulary to diagnose context failures before they become production issues.

• Actionable guidance for engineering teams to improve context hygiene and scale AI workflows safely.

Register here

Thanks to DX for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

In one of the previous articles, titled The “Player-Coach” Role is Becoming Increasingly Harder, we talked all about how the role is actually getting harder than it was before.

And the problematic part is that many people don’t understand that and don’t give the deserved credit.

Today, we’re diving deeper into how to actually do the coach part the right way!

This is an article for paid subscribers, and here is the full index:

- Great engineering leaders create leaders
- The difference between coaching and mentoring
- Make the mindset shift from telling to coaching
- Having a coaching mindset is all about asking great questions
🔒 Practical frameworks
🔒 The Solutions Focus model
🔒 The CLEAR model
🔒 Use the core skills for being a great coach and mentor
🔒 How to practice?
🔒 Great leaders multiply others
🔒 Last words

Let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published later this year.

Learn more about the book

Great engineering leaders create leaders

I view all the “player-coaches” as engineering leaders, and one of the most important things a great engineering leader does is create leaders.

And to do that, you need to become a great coach and mentor who elevates everyone around you and helps others grow.

You’ve probably had one or more managers in the past who you didn’t see as great managers, and the exact reason for that is that they weren’t leaders. They weren’t making everyone around them better through coaching and mentoring.

To have a great career as an engineering leader, you need to know and understand how to do coaching and mentoring the right way. Let’s go into more details next.

The difference between coaching and mentoring

It’s crucial to understand the difference between coaching and mentoring, so let’s cover that first.

Coaching

Coaching is normally short-term oriented with a specific goal, such as helping someone solve a specific problem or get better at doing something. The focus should be on asking the right questions and guiding the person to finding their own answers.

Mentoring

Mentoring is normally longer-term and about building a good working relationship by sharing your own experiences, offering advice, and being a good role model.

It’s really important to know when to wear the coaching hat and when to wear the mentoring hat. Great leaders know this and are good at both.

Make the mindset shift from telling to coaching

As engineers, it’s in our nature to share what we know and go straight to finding solutions. I like to say that we are “born problem-solvers”.

But to be a great coach and mentor, you need to move from “telling” to coaching. It’s a hard mental shift to make, but it’s crucial.

If you just give people answers to their questions, they won’t get any better at finding answers themselves. And they’ll expect you to just give them more answers in future.

That’s what happens when you have the “telling” mindset.

But instead of just “giving them a fish,” you want to teach them “how to fish”. That’s what you’ll do if you have a “coaching” mindset, which is a lot more powerful because it lets you guide others to finding the solutions to their problems themselves.

Having a coaching mindset is all about asking great questions

Here are some of the questions that I personally like to ask, whenever I’m coaching:

• “What have you already tried?”

• “What would you say is the main problem here?”

• “What are some different ways you could approach this? And what are the pros and cons of each?”

• “What resources or what particular person might help you find the answer?”

This may seem A LOT slower at first, but, in the long run that’s going to make a big difference.

You will boost their confidence, critical thinking and independence, which they need to become resourceful so they can solve new problems by themselves.

As a leader, your job is not to be the smartest person in the room, it is to build a team full of smart and capable people.

Practical frameworks

Read more

This newsletter is sponsored by orq.ai.

Your next engineer might not be human

Coding agents improve individual productivity. Orq.ai’s Software Factory goes further, it turns your SDLC into a governed production system, from backlog to shipped change inside your existing estate.

• Add engineering capacity. Autonomous agents plan, build, test and monitor.

• Keep humans in control. Critical changes and releases pass through human approval gates.

• Improve with every ticket. Each run adds organizational knowledge the factory can reuse.

Get in touch

Thanks to orq.ai for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

After you’ve chosen a direction for your career, either growing to a Staff Engineer, Architect, or become a manager, the next challenge is figuring out how to actually move toward it. Knowing what you want is important, but it’s only the first step.

You also need to communicate that direction and actively position yourself for the opportunity, and I learned this the hard way.

After I became a Senior Software Engineer, I didn’t know exactly what my next step would be. Because of that, I wasn’t very convincing to my manager in 1:1 meetings about what my career would look like in the future.

I couldn’t actually tell them, because I didn’t know. So I was stagnating in my career, feeling like I hit a wall. I didn’t know what particular skills to improve on, since I didn’t have the clarity of the next step.

It’s really important to have at least some idea of the direction in which you wish to grow. My promotion to Team Lead was more or less a combination of luck and the credibility I was able to build through successful projects in the organization.

I was asked if I would be interested in the Team Lead position and my manager at the time was surprised when I said yes.

I should have talked to my manager about my goals!

In this article, you can expect 4 actionable pieces of advice on making a move to your next step and make a convincing proposal to increase your chances. I’ll cover:

• Talking to your manager

• Keeping a brag list of all the wins that you achieve

• Become the go-to person for a specific project, specific technology, or specific domain.

• Propose an impactful improvement to the codebase and own the implementation

Let’s start!

My upcoming book “The Multiplier Mindset” published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published later this year.

Learn more about the book

1. Let your manager know about your goals

There are a lot of different types of managers, and some are easier to talk to than others. But, no matter what kind of manager you have, you should tell them about your goals and aspirations as soon as possible.

If they don’t know about your goals and how you wish to grow, they won’t be able to put you in a position to showcase your skills and get you to where you want to be.

What you say is important, but so is how you say it. If your manager senses excitement, motivation, or drive in you as you speak about your goals, they will react accordingly.

Let them know about the books and newsletters you’ve been reading, the courses that you are taking, and any other resources from which you are learning.

My advice is to let them know about your goals in a 1:1 meeting. Share your goals and aspirations and ask for direction on how you can get there.

For example, you might ask:

I’ve been reading about technical leadership. The book Staff Engineer by Will Larson has especially resonated with me for some time now, and I’ve taken a course on how to grow from a senior engineer into a lead role.

I also enjoy helping others navigate technical challenges, and contributing to broader technical direction, which is why I believe the Tech Lead role would be a good fit for me. What steps should I take in order to do that someday?

If you are already seen as credible and have a good reputation, your chances of success are much higher

Still, I recommend telling your manager sooner rather than later. Don’t wait until you’ve done everything to improve your credibility.

Ask first, then focus on strengthening your credibility. If you don’t get the response you hoped for, follow up again in a few months.

If you are already considered a credible person with a good reputation, your overall likelihood of success is much higher.

But I do recommend telling your manager sooner rather than later. Don’t wait to do all the things to improve: ask first and focus on all of these things, then you can potentially follow up on your ask.

My personal story of how important is to let your manager know about your goals

I struggled in my first few months as a Team Lead, what made me a good engineer didn’t work for me as a Team Lead.

After many mistakes and some wins, I got the hang of the new position, and started to believe that management might be the right path for me.

The manager who had promoted me left the company for another role, and their position became available. I spent some time contemplating whether I should ask about the position.

And then I decided to do it.

I let my former manager’s manager know that I believe I would be a good fit for the role and that I would be happy to take on additional responsibilities.

He said he would get back to me.

After a couple of days, he offered me the role of Engineering Manager, which I accepted. I moved from leading 1 to leading 3 teams.

This was one of the biggest steps in my growth. I learned a lot in that role, and it positioned me for my next role as Head of Engineering.

The moral of the story is that when you have a goal, you should always let your manager know as soon as you can, because you never know what opportunities may come to you.

Notion template: Tell your manager about your goals and aspirations

Use this template to help you define your pitch to share your goals and aspirations with your manager.

Paid subscribers, you can get the template here: 🎁 Premium products.

2. Keep a brag list

It’s really important to focus on working on things that are impactful and try to provide as much value as possible to the organization, but it’s also very important to note down what you achieve.

Not only should you have a ready answer whenever someone asks you about your achievements, keeping a list of all your achievements is also very good for your well-being and motivation.

I personally use Notion to note down my wins, but you can use any tool that works for you.

First, define your goals. These might be goals for the upcoming year, month, or even week, it’s up to you. Put your goal at the top of your list: “Get promoted to Team Lead,” for instance.

Whenever you make a certain achievement, note it in the list so nothing gets lost when it’s time to talk about promotions.

Have you successfully onboarded a new engineer? Are you mentoring others? Did you play a key role in an important project? Definitely write all of this down.

Your manager only sees about 40% of the work that you do, so it’s important to let them know about all the great things you do that they might not know about.

The rule of thumb I like to use when including wins in a brag list is that more is better: note down every win, large or small, that is aligned with the goals that you wish to achieve.

Keeping a “brag list of wins” helps you a lot with the impostor syndrome as well

Keeping a brag list increases your personal motivation and sense of success. Impostor syndrome is unfortunately quite common in our industry, and keeping a list of the wins that you have achieved is a great way to battle against that.

Your list reminds you how far you have come and that you deserve to be here. It’s also a good reminder that having a bad day doesn’t mean you’ll have a bad month or a year. We all have ups and downs.

You want to make sure that the “downs” don’t get to you and that you’re still moving in the right direction.

I am a self-taught engineer, and at the beginning of my career, I thought that university graduates must all have amazing programming skills and that I would never be able to get to their level.

I was focusing on what I might not achieve and what others had achieved, instead of on what I actually had achieved. I was learning for whole days and enjoying it, which helped me to progress very quickly. A brag list would have helped me to see that progress.

If you consistently keep your achievements in the list, you will more clearly see what you’re good at

When I did start keeping a list, I was surprised to find that the next step for me was right there, clearly visible in my wins!

What the list made clear to me is that I am good at collaborating, communicating, and managing people’s expectations, especially when it comes to projects and functionalities.

That suggested that management was the right path for me. It turned out that I was right.

Notion template: List of achievements

Use this template to note down all of your achievements. This will ensure that you are ready if someone asks you and that you stay motivated!

Paid subscribers, you can get the template here: 🎁 Premium products.

3. Become the go-to engineer in your organization

Becoming a “go-to person” means you are considered someone others go to when they need help or have a question about some specific topic.

It shows that you have credibility: others consider you an expert on that topic and trust your opinion and judgment.

When I started programming, I didn’t think I could actually be considered an expert in any specific technology. That was my impostor syndrome talking!

But the more I grew as an engineer, the more I knew that my skills were on par with those of my colleagues. Let me tell you how I first became the go-to person in my workplace.

How I became the go-to engineer

The company I was working for decided to move its app from using server-side rendering to client-side, using Angular.

I was very excited about this change and took the opportunity to start proactively learning Angular in my spare time. I particularly learned a lot from a course by Maximilian Schwarzmüller.

This learning made me the most knowledgeable engineer in my organization on Angular, which automatically made me the go-to person. That’s when my value grew substantially.

Everyone was coming to me with questions and issues, so it was a natural next move for my manager to put me in charge of our overall architecture, maintaining its style guide and guidelines, and onboarding new engineers.

This work sped up my progression substantially and helped me to grow toward becoming a Senior Software Engineer and eventually a Team Lead.

Later, after I changed companies, my new employer switched from using Vue to React. I tried the same approach, taking ownership and responsibility for many different React projects, which got me the offer to become a Team Lead.

3 main ways to become the go-to person

You either become the go-to person for a specific project, domain, or technology.

Choose the one that best plays to your strengths.

1. Project

Take ownership of a project and make it your responsibility to get everyone on the same page and ensure that everyone is building the right things.

You may ask: isn’t this the product or project manager’s responsibility? Well, the product manager doesn’t understand all of the technical details, but you do.

So an engineer who takes ownership and responsibility for the project, gets everyone on board, and ensures that deliverables are done right and on time is very valuable.

2. Technology

Whichever technology you work with currently, become the go-to person for that technology. This can be a specific framework, language, or overall field, like frontend, backend, QA, or DevOps.

Ideally, you’ll be an expert in one specific thing and very good at a lot of other things. That way, you can have great discussions about basically any technology while providing an expert opinion on one specific topic.

Others will naturally go to you for specific questions and issues, which will make you very valuable for the team and the overall organization.

Once your knowledge approaches expert level in a specific technology, here are some ways to make sure that others consider you an expert:

• Host learning sessions inside your team or across the organization to share your knowledge with others

• Start writing: post on LinkedIn or start writing a blog or a newsletter.

• Focus on helping others. Word will travel fast that you are a knowledgeable person who likes to help when needed.

3. Domain

In every organization, there are specific domains, like payments, orders, products, and news.

If you work on an application with a monolithic architecture, those domains are called modules; in a microservices architecture, they’re services. Every domain has specific business logic related to it. My recommendation is to take ownership of the domain you work on.

Some ways to do this are:

• Create documentation as needed and keep existing documentation up to date. Consider creating an FAQ page as well.

• Make sure your domain works flawlessly and that you can quickly spot issues when they arise.

• Put good monitoring in place and continuously check for unusual activity or other signs of a problem.

• Help others onboard quickly and become productive in your domain.

• Be available to answer colleagues’ questions.

Engineers who aren’t afraid to take ownership and responsibility are highly desirable

When they also make others around them better, they provide a lot of value to the engineering organization and the company.

You can’t, and don’t need to become the go-to for everything. Become the go-to for one thing and do that well. Going deep is what provides the most value.

Think about it like this: if one person in the organization takes really good care of a specific part of that organization, everyone in the organization benefits.

Let’s define what a go-to person should and shouldn’t do. Your focus should be on making it easier for everyone to get started on and work with whatever domain, project, or technology is your specialty.

Here is what you shouldn’t do:

• Treat your knowledge and context as something to guard rather than share

• View colleagues as competition instead of collaborators

• Work in isolation rather than inviting feedback

• Protect your domain instead of enabling others to contribute

Here is what you should do:

• Spread knowledge and awareness about your area of expertise

• Create documentation and learning documents for others to use

• Provide support and onboarding; be helpful to others working on your area of expertise

Notion template: Become the go-to person

Use this template to list down your projects, domains and technologies. This will help you to choose on what you can become a go-to person.

Paid subscribers, you can get the template here: 🎁 Premium products.

Now, let’s go to the next important thing that you can do to showcase your value and increase your chances of getting promoted.

4. Propose and implement an impactful improvement

Engineers who truly stand out are the ones who find impactful work to do without being asked, then take ownership to execute and implement it as well.

You can do this by yourself or, even better, bring in other team members and deliver the improvement together. Don’t just wait for assigned tasks: that limits your growth and the value that you can provide.

Why should you propose an impactful improvement to the codebase and own its implementation?

1. First, it shows everyone that you aren’t just here to focus on your own tasks, but to make things better for your team and organization.

2. Second, every time you work on something new, you learn something new as well. It’s a chance for you to expand your horizons with a new framework, technology, or domain. Getting comfortable with being uncomfortable is the way to grow.

3. Third, this strategy gives you an opportunity to lead a project, which is especially important for growing towards lead roles. You’ll need to establish a track record of successfully leading and finishing projects.

4. Fourth, once you do this, your overall reputation will grow substantially, bringing you far more opportunities. You’ll also make a better first impression on people you meet.

But here is the most important reason to propose an impactful improvement to the codebase and own its implementation: It will get you promoted.

There are many reasons why, but in short, you are showing that you are proactive, that you aren’t afraid of taking responsibility and ownership, and that you can deal with ambiguity and successfully finish projects.

One of the most important things managers look for in engineers is the ability to take not-so-clear requirements and deliver the exact solution needed, without supervision.

That’s what I look for: I promote engineers I can rely on to solve a problem on time and with high quality. Do this enough and you’ll attract unlimited opportunities.

How do you find the improvements that will make a real impact?

Listen, and then solve the problems nobody wants to deal with, additionally, listen to the problems and challenges of your team, other teams and departments (product, design, sales, marketing, compliance, and so on), and the overall engineering organization.

If you understand their problems, you can find technical solutions that would help solve them. Imagine implementing something that will save the marketing or sales team thousands of hours. That provides a lot of value!

Put yourself in other people’s shoes and ask yourself what you can do to help the most. Ask questions and make sure you understand the business challenges involved. Try to think like a product manager!

Also this is very important as well, when you hear about recurring issues, the best thing you can do is to try to solve them.

There may be some parts of the codebase that are really hard to understand, parts that are missing documentation or tests, or parts whose quality nobody feels confident about.

Not only will your fellow engineers, your manager, and the whole organization appreciate you for doing this, you’ll be showing the courage to face the issue and grit to resolve it, and that will set you apart.

Once you find an improvement to suggest, how should you propose it?

How to propose an impactful improvement?

The answer depends on the scope of the improvement and the impact behind it. For quick improvements, I highly suggest just doing it. If you are not sure about it, get some feedback from your team members first.

But if you are sure, you don’t need to get permission to make things better, just fix things. Create a task and open a pull request with the changes.

If the fix takes more time, talk to your manager, PM, or Tech Lead. Make sure to write down your reasons for proposing the improvement and clearly describe the impact, the risks, and the approach you are proposing.

You want to make it as easy as possible for the relevant person to say yes.

Finally, and most importantly, when you propose the improvement, volunteer to lead its implementation. Make it clear that you wish to take ownership of resolving the problem.

If you don’t do that, leading the implementation work could be assigned to someone else, and you’d lose out on that experience.

This has been very impactful for my career

Proposing and implementing impactful improvements has substantially helped me grow in my career, both within my full-time roles and when doing freelance work. I’ve been able to deliver exactly what clients are looking for.

The funny thing is that the initial requirements are always something different than what they really needed. I’ve learned to ask the right questions and propose solutions in ways that ensure we actually build the right things.

Last words

Let’s end this article with the following:

Doing all these 4 things we mentioned above will increase your reputation substantially and increase your chances of getting promoted.

The key is not to wait until someone gives you permission to operate at the next level.

Start creating impact beyond your own work. Take ownership of problems that nobody explicitly assigned to you. The title usually comes after you’ve already shown you can operate at that level.

You got this!

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

This newsletter is sponsored by G2i.

The bar for “good engineer” moved, your hiring process didn’t.

A year ago, using AI for coding meant using 1 AI agent at a time. Now it means orchestrating 3 or 5 at the same time, with the focus on the right code quality as well.

If your tech interview process still tests for pure syntax, you’re screening for a job that doesn’t exist anymore.

• Live session, judged by a real person in real time

• Scores RL, RAG, agentic development, and eval judgment

• Built from two years inside frontier AI lab work

• Vetted senior and staff-level engineers with 10+ years building production systems

See how G2i evaluates real engineering judgment:

Learn more

Thanks to G2i for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

Throughout this year, I had the pleasure of talking with many different people and teams about how everyone works and what makes them successful.

I’ve visited many companies in San Francisco and had countless conversations with engineers and engineering leaders from companies around the world.

In today’s article, I am sharing insights, particularly about what differentiates elite engineering teams from the average ones.

The insights shared in this article are from:

• Sulman Choudhry, Head of Engineering, ChatGPT, OpenAI

• Venkat Venkataramani, VP of Applied Infrastructure, OpenAI

• Katelyn Lesse, Head of Platform Engineering at Anthropic

• Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock

• Andrew Churchill, CTO, Weave

The question I asked them was: “What separates elite engineering teams from the average ones?” Their answers are shared in this article.

This is an article for paid subscribers, and here is the full index:

- Elite engineering teams focus on the “outer loop”
- Clarity on the north star and good metrics in place in order to measure success
🔒 At Anthropic, elite teams are more ambitious than average teams
🔒 Team tenure and committed work say a lot about how great the team is
🔒 Elite teams work within flatter orgs and have a good ratio of spending and delivering values
🔒 Last words

Let’s start!

Elite engineering teams focus on the “outer loop”

Sulman Choudhry, Head of Engineering, ChatGPT, OpenAI, described the difference between an average team and an elite team using the idea of the inner loop and the outer loop of software development.

The inner loop refers to shipping or writing code faster. But the problematic part is that more code is not always better. Many average teams are already good at this, they build quickly and produce a lot of code.

However, the real difference appears in the outer loop.

The outer loop is about getting real user feedback, learning from it, and quickly iterating to improve the product. Average teams often run into bottlenecks here.

Elite teams optimize both loops. They not only write code quickly but also build systems that help them test ideas, gather user signals, and iterate faster toward real outcomes.

And the example Sulman has shared:

Instead of writing code and manually testing it, elite teams use tools like Codex to test and iterate as part of the development workflow. This helps them get to the desired result much faster.

The ultimate version of the outer loop connects development directly to real user outcomes, such as product usage or user engagement.

So, to sum up the insights shared from Sulman:

• Average teams mainly optimize the inner loop, focusing on writing/generating code faster.

• Elite teams optimize the outer loop, learning faster and driving real impact.

What matters most is impact, not the amount of code written.

Clarity on the north star and good metrics in place in order to measure success

Venkat Venkataramani, VP of Applied Infrastructure, OpenAI, mentioned that for a shorter time period of the work of specific teams, it’s easier to see whether the team is doing well or not, because there are clear deliverables and well-defined metrics attached to it. It’s a lot harder to know if the project takes a long time to finish.

This is an important signal for infrastructure teams to break down projects into smaller, more manageable pieces, because that’s how you can show your progress a lot more clearly.

And the 2 specific high-signals of elite teams Venkat shared are:

• Does the team have clarity on what the north star looks like? (long-term goal of the team) And are they able to hit that goal as well?

• Another signal is if the team doesn’t have specific metrics in place that they track in order to know how well they are doing.

And then he also shared the following:

For every infra team, there’s always a time when there needs to be some “hill climbing”, which means that the team may be overwhelmed with the amount of work in a certain period of time because of how unpredictable infrastructure work can be.

Great teams are able to balance that short-term pressure well, without losing sight of the long-term goals.

Which means that they don’t just put “all hands on deck” when there is a certain pressure, but they stay composed, assign specific people to focus on the right areas, communicate clearly if there’s going to be any timeline changes on projects, and manage to juggle everything without dropping the ball.

At Anthropic, elite teams are more ambitious than average teams

Read more

This newsletter is sponsored by Unblocked.

[Webinar] How to stop babysitting your agents

Agents can generate code. Getting it right for your system, team conventions, and past decisions is the hard part. You end up wasting time and tokens in the correction loops.

More MCPs, rules, and bigger context windows give agents access to information, but not understanding. The teams pulling ahead have a context layer to give agents exactly what they need for the task at hand.

Join live on Sep 2 (FREE) to see:

• Where teams get stuck on the AI maturity curve and why common fixes fall short

• How a context layer solves for quality, efficiency, and cost

• Live demo: the same coding task with and without a context layer

If you want to maximize the value you get from AI agents, this one is worth your time.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

For a long time, moving up in engineering meant becoming less hands-on. You would spend less time building and more time leading, delegating, and enabling others. That is changing.

Engineering Managers, Tech Leads, Team Leads, and Architects are increasingly expected to be “player-coaches”. To be great leaders while also staying deeply involved in the technical work. It sounds great on paper. But here’s the problem:

We are adding more expectations to roles that were already difficult to do well.

AI was supposed to make the “player” part easier. In many ways, it’s doing the opposite, and in this article, I’ll share all about why that’s the case, and at the end, I’ll share my advice for both the leaders and player-coaches.

Let’s start!

What does being a “player-coach” actually mean?

We’ll start with this very important question because it’s crucial that we know and understand what it actually means and what the main responsibilities are.

A player-coach is someone who operates in 2 modes:

• They are a coach

They set direction, develop their people, give feedback, ensure everyone understands the goals, remove blockers for others, coordinate with other teams, while making sure that the team is also efficient.

• They are also a player

This might mean they are writing/generating code, reviewing/creating technical specifications, resolving production issues, building MVPs/prototypes, etc. Everything that a senior engineer would do.

The main associated roles of player-coaches are: Engineering Manager, Architect, Team Lead, Tech Lead.

Now, the main question you might have is: This sounds like 2 different jobs? How do you actually manage doing 2 jobs at the same time?

How do you actually do the work of a player-coach?

This has been an endless problem to figure out, especially for people who found themselves being in such position for the first time. The first-time tech leads, team leads, EMs, or architects.

You have a limited amount of time every day, you have a limited amount of mental energy every day, and you need to decide where to put your focus. There are endless things to do, but it’s crucial that you know what to work on and what not.

So, not only do you need to have both good people skills and tech skills, you need to be extremely good at managing your time and priorities.

And the biggest problem that I also had as a first-time lead was saying “no” to things that are not important, and trying to help everyone at the same time.

I found myself in so many different situations that “needed my help”, so that it became totally unmanageable. And it was either stop doing it or you’re going to burn out.

Learn how to manage your time in this article:

AI makes the player-coach role harder, not easier

The roles have been hard enough already, now, with AI, the role is harder than ever.

You might think that the “player” part is now easier, because you can just use AI to “do it for you”. In some cases, that is true, like creating a PR based on a clearly defined task is a lot easier.

But the problem is that there are 3x more PRs being created today than in 2024. And teams that use AI coding agents to develop their software create 6x more PRs than traditional teams.

And as we know, AI-assisted engineering is the standard way of developing software these days, so most teams are using AI coding agents, and if they are not already, they definitely should.

So, the reason why this is problematic is that the “player-coaches” are the ones who are most of the time responsible for the success of a certain project. And as I wrote in one of the past articles, code review is the new bottleneck for engineering teams.

With the speed of coding increasing, what happens is that a lot of reviewing falls onto these player-coaches to ensure that everything is on point.

And as you know, reviewing has always been a really draining part of software development, it’s much more satisfying when you are building than when you are reviewing other people’s code. That’s especially true for me.

So, based on my conversation with many engineering leaders across the industry, a lot of the work these days is actually reviewing other people’s code.

And what can be really problematic is when certain engineers don’t review their code correctly, and they just blindly submit “AI-generated slop”.

And that surprisingly happens quite often, especially with more junior engineers, where that engineer opens a PR full of AI-generated slop, and then it’s on the reviewers to find all the issues with it.

The unrealistic expectations of player-coaches

And then the real problematic part is that the “AI-generated slop” is actually incentivised across many companies these days, and a lot of leaders don’t actually understand that more code is not better.

We see people bragging that they are generating 50k lines of code per day, or even 100k, and many people think that this is “cool”. But here is the reality:

Less code and better code is much better, because less code means fewer problems and less maintenance we need to do.

With code that’s not needed, we are just creating future problems that we don’t need.

So, what happens is the following:

• Engineers are incentivized to create more

• Everyone is incentivized to create (you may have heard of a new important skill for non-tech people to “ship to production”)

• Company leaders don’t understand the bottleneck comes on to reviewing and ensuring the software is built with the right standards

• Company leaders think that you can do the “player role” with ease now that AI is here to do all the work and magic

This creates a ton of more work for these player-coaches, with no extra credit for them, because of the lack of understanding of what’s really important.

I’ll be sharing my advice for both company leaders and player-coaches next.

My advice for leaders who are managing player-coaches

Whether you are a Director, VP, CTO, or CEO, make sure not to fall into the story that “AI can just magically do everything for you”. It definitely helps in certain areas, but then creates a bottleneck in another area.

It’s your responsibility to figure out where that bottleneck is and provide the necessary support to the people who need it.

And that specific area is good judgment, which is a crucial skill that player-coaches must have in order to do well in their roles.

My advice is to really listen to the people who are at the root of these bottlenecks. The worst thing you can do is to just blindly “dismiss” it and keep on incentivising people to create more by using AI.

The people who are really important for the success of projects are going to be burning out because of the lack of understanding of how important their work is.

And at the same time, make sure to give credit where credit is due. Not just to people who “create more”, but to people who do the “glue work”, put so much effort into reviewing PRs, and proactively communicating with everyone to ensure that the project is still on track.

I know such work is often less visible, and that person must make that work visible. My advice is to keep your eyes on the lookout for people who are doing such work and ensure that they get the well-deserved credit.

My advice for player-coaches

Now, here comes the hard part, you are doing a lot of extra work, while people don’t really understand that your work is a lot harder, not easier.

The problematic part is that you can’t say that it’s the “leadership’s fault”, well in reality it is, because they might not understand how important your work is. But if you put the blame on others, there are no actionable things for YOU to do. And that’s the wrong mindset to have.

The best mindset to have is: “What can I do in order to ensure that people understand how important my work is?”.

The first thing is credibility and trust. You need to build both, because without them, your word doesn’t have weight, especially with the leadership.

The second thing is to actually have conversations with people about your work, and ensure that you communicate your impact correctly. You can “assume” that people know that already, but more often than not, they don’t.

Your manager sees about 40% of the work you do on a daily basis, it’s your responsibility to communicate the rest to them.

I wrote extensively about both how to build credibility and trust, and how to actively communicate your impact in these 2 articles:

I highly recommend you give them a read, they will help you a LOT with ensuring that you are viewed as a highly credible professional, and that everyone understands the impact of your work.

Last words

The “player-coach” role has never been easy, and with increasing expectations, it’s becoming even harder.

Let’s end the article with the following:

AI makes it easier to create more, but someone still needs to review, prioritize, make good decisions, and ensure everything fits together. And a lot of that responsibility falls on player-coaches.

If you are in such a role, remember, you can’t do everything. The key is knowing where your involvement creates the biggest impact, and saying “no” to everything else.

That’s what being a great player-coach is really about. You got this.

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Check out my book “The Multiplier Mindset” coming out later this year, here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

Check the benefits of the paid plan

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.

This newsletter is sponsored by Honeycomb.

Live Masterclass + Q&A: The Business Case for Observability

Observability is a significant engineering investment. On September 2, Honeycomb’s Liz Fong-Jones, co-author of Observability Engineering, will break down how engineering leaders can evaluate that investment, connect observability to meaningful outcomes, and build an evidence-based case for what comes next.

In this virtual masterclass session:

• Evaluate observability against engineering outcomes

• Identify gaps between monitoring and effective observability

• Build an evidence-based case for future investment

Register now and watch what you missed

Thanks to Honeycomb for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I recently had the pleasure of speaking with Eric Sammer, Distinguished Engineer at Redis (formerly CEO Decodable).

We talked all about how Redis builds AI-native engineering teams, their process, culture, and also how they do hiring.

Interestingly, their engineering culture revolves heavily around performance. Not surprising, though, as performance plays a huge part in Redis’s products, and they work within pods of 3-4 engineers, each with a feature lead.

This is an article for paid subscribers, and here is the full index:

- What does AI-native mean at Redis?
- The size of Redis’s product&engineering org
- Redis’s AI-native teams structure
- Their meetings and process
🔒 How are they using AI to be more productive?
🔒 They are measuring token spend, but how effective the spend is is the hard part
🔒 Redis’s engineering culture
🔒 Hiring process for a new engineer
🔒 Last words

If you haven’t read the articles on how OpenAI, Anthropic, and Shutterstock build AI-native engineering teams, I highly recommend doing so:

Let’s start!

What does AI-native mean at Redis?

As with every article about AI-native teams, I always want to understand what AI-native really means for a particular company, and this is what Eric mentioned:

I think it’s similar to “cloud native”. It’s a term people use to mean almost everything and nothing.

To me, being AI native means treating AI as a default way of working, not as something you simply add on later.

The question I like to ask is: If we were building software engineering from scratch today, and AI already existed, what would it look like? How would we build teams, processes, tools, and technology differently?

That’s what AI native means to me. And I think cloud native is a good parallel.

Especially interesting is the parallel to being cloud native, which resonates, because when companies started to shift from on-prem to cloud, quite some time ago, that term got quite similarly sensationalized as AI-native is today.

The size of Redis’s product&engineering org

I was quite surprised to hear that Redis has about 350-400 people across the product and engineering org. They really came a long way from when Redis was just an open-source project started in 2009.

Engineering makes up the majority of that headcount, and around 20-25 people are in product. That’s about a 1:15 PM-to-engineer ratio. Very similar to what Shutterstock does. While Anthropic has a 1:8 ratio and OpenAI has 1:30.

One of the more interesting changes Eric has mentioned is that, looking from 2 years ago to today, there’s a lot less specialization of engineers, and a lot more engineers who are good generalists.

I wrote about this exact trend in this article: Become a Great Generalist or Extreme Specialist.

And he also mentioned that PMs don’t just work on creating PRDs or designing in Figma, but they actually build working prototypes in React and Claude Code.

Redis’s AI-native teams structure

They work within small pods of 3-4 engineers. Every team has a feature lead, which is basically a tech lead, leading the technical implementation of a certain project that the team is working on.

And these teams work with other teams, and people e.g. PMs, designers, customer support etc. when needed.

This is very similar to how OpenAI builds their AI-native teams, just the difference is that the feature lead is called the DRI (directly responsible individual), for both technical and product/business as well.

Eric also mentioned that the teams have support from higher-level engineers e.g. Staff, Principal and Distinguished engineers when needed.

These higher-level engineers are normally also called service leads, they lead specific larger functionalities and ensure that the teams who are building these related projects are aligned with the standards.

Their meetings and process

These teams can generally decide what the best way is to handle meetings and the overall process. Some of these teams work within 2-week sprints, and every team decides how many meetings they need.

Eric mentioned that this is something they are still figuring out and evaluating what the best way to go is, and he sees that alignment is more important than ever. This is what he mentioned:

I’ll be honest, I don’t think we’ve fully figured this out yet. It’s something we’re constantly evaluating to see if there’s a better way to work.

In the past, the biggest bottleneck was writing code, testing it, and getting it into production. Now, the bigger bottleneck is how quickly teams can align and make decisions. The more people you have, the harder that becomes.

That’s why I think frequent communication, like daily stand-ups, is more important than ever. They help teams spot when something is off, when people aren’t aligned, or when they don’t understand why we’re building something.

These stand-up meetings are also less about the technical details and more about timelines, priorities, and cross-team dependencies these days.

Planning also needs to move much faster. Some teams still use traditional 2-week sprints, but a lot can change within those 2 weeks.

Roadmap and prioritization decisions used to happen every couple of weeks. Now, they can happen every few hours. A team might finish something much faster than expected, and suddenly you need to figure out what they should work on next.

My feeling from talking with many different teams is that nobody really has it figured out, and everyone is learning as they go, even Anthropic and OpenAI, they are constantly evaluating and adjusting how they work.

How are they using AI to be more productive?

Read more

Read more

This newsletter is sponsored by Sonar.

Cut AI coding token costs by up to 36% with Sonar Vortex

Sonar Vortex operates directly within your AI coding agent’s reasoning loop to supply architectural context before any code is written.

By verifying output in real time, it empowers you to build safer, higher-quality software while significantly reducing your LLM spend.

• Slash Token Costs: Testing showed reduced LLM token consumption by up to 36% on coding tasks.

• Reduce Bugs: Lowered software defects by 92%.

• Smarter AI Context: Equip your AI agents with deep architectural context before they generate code.

Make your agents more effective

Thanks to Sonar for sponsoring this newsletter. Let’s get back to today’s thought!

Intro

I’ve been using Shutterstock’s platform for quite some time now. Whenever I needed a stock image, it was usually one of the first places I’d look.

But in recent years, Shutterstock has been adding a lot of new features and capabilities, especially around AI. It seems they went from focusing primarily on the stock content business to a company focusing a lot more on AI/ML.

A similar transformation I’ve seen with Canva as well (just in a different industry).

That was one of the reasons why I was excited to talk with them and learn how they think about building AI-native engineering teams.

I’ve recently had the pleasure of talking to Jefferson Frazer, Director, AI Metadata and Delivery, Shutterstock.

He shared a lot of interesting insights on how Shutterstock works and builds AI-native engineering teams, which I am sharing today in this article.

This is an article for paid subscribers, and here is the full index:

- What does AI-native mean at Shutterstock?
- How big is Shutterstock’s engineering org?
- The structure of their AI-native engineering teams
- The process of AI-native engineering teams
🔒 How are their engineers using AI?
🔒 Advice for writing good prompts
🔒 How do they track token spend?
🔒 What makes an elite versus average engineering team?
🔒 Shutterstock’s engineering culture
🔒 Being vocal and having an opinion is a very important trait
🔒 Hiring process for a new engineer
🔒 Last words

If you haven’t read the articles on how OpenAI and Anthropic build AI-native engineering teams, I highly recommend doing so:

Let’s start!

What does AI-native mean at Shutterstock?

This has now become a standard question that I ask different companies, and the reason is that “AI-native” means different things for everyone. Here is what it means for Jefferson and Shutterstock:

AI-native means that AI is integrated into everything that we do, all the way from coding and architecture to design, and also providing a good experience to our customers.

An interesting thought that he mentioned is that they want to provide the same kind of experience their people have internally using AI tools to Shutterstock’s customers as well. With AI workflows and experiences on their platform.

How big is Shutterstock’s engineering org?

Jefferson mentioned that they have been flattening a bit of their organization over the years, and they want to have an organization that is engineering-heavy.

They have about 350 engineers inside the org, across a lot of different time zones and countries. Their product org is kept purposely small, as they want their product managers to be working across different engineering teams.

And designers work more directly with product managers. The goal is to have the engineering teams autonomous as much as possible, and then bring in additional people when needed.

The structure of their AI-native engineering teams

Their AI-native engineering team structure is similar to Anthropic’s. They also work in a 2-pizza team setup with 5-8 engineers as part of the team and an engineering manager leading the team.

The big difference is that they have about 1 PM for every 2 teams, so the ratio is about 1 PM for 10-15 engineers. Also, product design is not a part of the cross-functional team, and it’s utilized when there’s a need for it in parts of the projects that the teams are working on.

Another big difference is that they have 1 dedicated Tech Lead inside the team, who is responsible for everything technical regarding the projects, but there can also be additional owners of certain projects inside the team, but primarily, one person is the main tech lead of the team.

Jefferson also mentioned that not every engineer is expected to be full-stack, the goal is to have all different skill sets covered in the team, so the team can be as independent as possible.

In practical terms, that means that some engineers may be a lot better in frontend, some better in backend, and then some better in DevOps, AI/ML, etc.

And one important thing as well is that they encourage their engineers to change teams if that’s their preference, in order to grow and develop various skill sets. To quote from Jefferson:

I can think of at least a dozen folks internally who have spread their wings and moved into different teams, picked up new languages, started working on front-end when they were back-end engineers, etc., and really developed their careers here.

The process of AI-native engineering teams

Their product teams work within 2-week sprints and use Scrum as their way of working, which is the same as traditional teams.

So, they have all the meetings like traditional teams: daily meetings, planning, retrospectives, etc. And there’s also a sprint demo meeting at the end of every sprint.

Additionally, at Shutterstock, they also have dedicated ML engineering teams, and they work a lot differently than product teams.

These teams work within 6-week “bet cycles”, where they focus on achieving a certain goal within the 6 weeks. No Scrum or Kanban.

The reason for quite a different workflow than with product teams is that ML work is a lot more unpredictable, and you can’t really promise certain outcomes in X amount of time. You see what may be possible based on the research that you do.

How are their engineers using AI?

Read more

Read more

Intro

The Forward Deployed Engineer (FDE) role has gained a lot of popularity in recent years, and OpenAI is a good example of fast scaling of their FDE organization.

Additionally, they recently built a separate entity called the OpenAI Deployment Company, focused on helping customers use OpenAI’s products.

I had the pleasure of talking with Colin Jarvis, Global Head of Forward Deployed Engineering at OpenAI.

We talked all about how their team works, what makes a great FDE, how they work with customers, and how engineers can prepare for the role.

This is an article for paid subscribers, and here is the full index:
- How OpenAI built its forward deployed engineering organization
- Forward deployed engineer role at OpenAI
- What does an FDE do on a daily basis?
- About 50% of their time is spent on the customer site
🔒 The hiring process for a new FDE
🔒 Onboarding process for a new FDE
🔒 What makes an FDE successful
🔒 Moving from a software engineer to FDE, how to prepare?
🔒 Last words

Let’s start!

How OpenAI built its forward deployed engineering organization

OpenAI started the forward deployed engineering organization last year, with a focus on gathering insights from customers, learning what the use cases are, and bringing the insights back to product and research.

They started with just 2 people and have now grown to around 140 people in the FDE org. The FDE org sits between the GTM (go-to-market) org and product and research, working with both of them, acting as a “link”.

After some time working with different customers, they have noticed repeatable problems that people and companies are dealing with, and that’s also the reason why they recently started OpenAI Deployment Company (which is a separate entity, but still part of OpenAI).

It has now grown to about 200 people, and I suspect it’s going to grow a lot more in the future. Its goal is entirely to help solve customer problems, which is at the core of what FDE is all about.

Colin mentioned that they intentionally want to keep the internal FDE org at OpenAI relatively small and focused on getting insights for the product and research, but they want to keep expanding the OpenAI Deployment Company in order to support the customers in need of integrating their products.

Now, let’s get more into the FDE role in general.

Forward deployed engineer role at OpenAI

When I asked Colin on how he’d define the FDE role at OpenAI, he mentioned the following:

A forward deployed engineer is focused on outcomes. Which means that their goal should be to work on problems where solving them has a much bigger impact than the work itself.

So, in practical terms, the value is not in writing code, instead, the focus is to solve the problem and, ideally, make themselves obsolete as well, so they are not needed anymore.

And if they are needed again (for the same problem), that usually means that the problem has not been solved entirely.

They want strong software engineers, but at the same time also good communicators, who can really dig into what the actual problem is and explain the solution in a way that resonates with everyone.

And (ideally), these engineers would also have some domain expertise in the field that the specific customer operates in.

For example, a software engineer who has worked in the fintech industry could be a great fit for an FDE helping out a customer who works in fintech, because they understand the domain.

However, an important thing that Colin mentioned is that they want to mix the domain experts and FDEs, who are not. And the reason is that a person who is not an expert in the specific industry, but has experience from another, is going to be much more likely to “challenge the status quo” and have unique ideas to solve certain problems.

What does an FDE do on a daily basis?

Colin shared an example of a project they are working on at the moment in Japan, specifically for “code modernization”. That specific customer has a lot of legacy applications, and migrating one of these systems can cost hundreds of millions of dollars.

They are helping that customer with the migration from older tech to the new tech using AI.

An FDE might spend the full day talking with the payments team to understand what specific things are important to them so that the migration would be successful.

And then the next day, start building tests based on the insights shared from the payments team in order to ensure that the migration is actually successful.

And then another day they might be writing actual migration code, or building the UI to show the progress of the migration, and/or specific steps of it.

So the role is really a mix of engineering and working directly with domain experts (and also having a good understanding of that field), going back and forth between the two.

There’s also a feedback loop with the product and research teams that’s important. And in this specific project, they found out that a specific model used for the migration kept making some simple mistakes.

And as Colin mentioned, they don’t just send the exact customer problem back to the research team. They try to be as specific as possible, for example: “The model struggles with these types of COBOL-to-Java tasks. We need more training data around these examples.”

They’ll do whatever is needed to make a certain customer successful, but the bigger goal is to make sure the model keeps getting better for every customer.

About 50% of their time is spent on the customer site

They generally tell new joiners to expect around 50% of their time on site.

But also, as Colin mentioned, it varies by project. For example, some of their people in the UAE are on site around 80% of the time. People based in Europe or the US might spend 2-3 weeks per month with customers. In Japan, people are also on site around 80% of the time.

But in general, they focus on trying to have the biggest impact possible when on-site, and they’d rather spend 2 or 3 impactful days instead of 4-5 less impactful.

And also, a lot of their customers are spread across different locations, so being on-site all the time isn’t practical. But, as a general guideline, around 50% of the time on-site is a good estimate.

The hiring process for a new FDE

Read more

Read more

Intro

Back in December, 2022, based on your feedback, I wrote an article that has been very useful: How to have great 1:1 meetings. Also, the template included has been the most downloaded out of all.

And because the article has been helpful, I decided to do a 2026 extended version of it. So, in today’s article, I am sharing how to have great 1:1 meetings in 2026 and beyond.

This article is written from the perspective of a manager who is organizing and having 1:1 meetings with their direct reports.

It’s also important to mention that in many companies in 2026, a team lead or a tech lead may have 1:1 meetings with their team members, but they are not directly reporting to them. It works from this perspective as well.

This is an article for paid subscribers, and here is the full index:
- What has changed for 1:1 meetings in 2026?
- Make sure to schedule all your 1:1 meetings in advance
- Be on time
- Get your own 1:1 Notion template that I use
🔒 Meeting agenda
🔒 Focus on objectives, goals, and career development
🔒 Meeting notes
🔒 Last words

Let’s start!

Ready, Spec, Ship Hackathon with Kiro

I am happy to share that I will be a judge at the Ready, Spec, Ship Hackathon with Kiro.

There is a $9,600 prize pool available for the top 3 submissions. You can enter solo or form a team of up to three people. Build something ambitious, creative, useful, or completely unexpected with Kiro.

Excited to see all the great stuff being built alongside my fellow judges John Crickett and Angie Jones. Check out the details and enter here:

Check the details

Looking forward to seeing what you’ll build!

What has changed for 1:1 meetings in 2026?

Well, interestingly, not that much. I still use the same template for all the 1:1 meetings I have, and that’s also what I recommend. I’ve been a big fan of Notion for a while now (dating back to 2020), so I’ve been using the same Notion template for more than 6 years now.

Additionally, what I would say has changed the most is that while I keep all the 1:1 meetings very personal and human, I’d occasionally use AI to help me generate ideas for discussion points, brainstorm action items, and help frame certain feedback better.

While I find this helpful, I wouldn’t say AI has been remotely close to an important part of the 1:1 preparation. My goal with every 1:1 meeting is that I build a better working relationship, and that we can openly talk about things. Not try to AI-generate feedback, and sound like a robot.

Additionally, an important shift I notice in comparison to having 1:1 meetings today versus in 2022 is that it’s really important to acknowledge the shift that is happening in the industry with AI.

And it’s even more important to be a good manager and a leader at this time. That’s also one of the biggest differences about how people feel at work these days, in my opinion. The team they are a part of, and the manager they have.

So, with a lot more uncertainty about the future, it’s important to really be there for your team, have great 1:1 meetings, acknowledge the uncertainties, and do your best to support everyone.

Now that we understand some of the differences, let’s start with the basics.

Make sure to schedule all your 1:1 meetings in advance

So, that’s the first thing you should do, it’s important that you have a regular cadence of 1:1 meetings, and that you don’t just schedule them sporadically.

The reason is that if a meeting just shows up in the middle of the week, your report might feel like something bad would happen in a meeting, and they would be unnecessarily worried about it, which can cause a lot of stress.

As a full-time CTO, I heavily stuck to separating my time into manager time and maker time, with the manager time used for meetings, alignments, and slack/emails, while the maker time was for head-down time for deep work.

I organized all my 1:1 meetings on the same day, one after another, with a bit of a break in between. I usually prepared the day before for the 1:1 meetings the next day. A 30-minute meeting is also a standard for a 1:1 meeting.

You can read a full overview of how I organized my time as a full-time CTO in this article:

Checking in with your reports to see if that specific time works for them is also my suggestion, so it doesn’t feel like the time is forced. And in general, this meeting is for your report, not for you, so finding the right time that works for them is important.

Be on time

I’ve had a lot of 1:1s with the managers, who just showed up late to the 1:1 meeting. Sometimes, they would send a message that they’d be late, another time, they would just show up late, with just 15 minutes left in the meeting.

Experiencing that, I focus a lot on being on time as much as I can. Of course I am not always perfect, and it happened to me as well. But at least if I’m late, I send a message. But I do my very best to be on time for the meeting.

Everyone’s time is important, not only yours. And if you treat people like their time is not important, it’s not a good look, and it’s an awful way of building a good professional relationship.

Don’t try to justify that you are a “manager” and that you’re very busy. How you treat your people on a daily basis tells me everything about what kind of manager you are.

Always keep this in mind.

Get your own 1:1 Notion template that I use

This is the exact template that I have been using for the past 6 years, and it works great!

If you want to always be prepared for your 1:1 meetings and need a system to organize all of your notes, make sure to use this template.

Paid subscribers, you can get it here: 🎁 Premium products for paid subscribers.

Meeting agenda

Read more

This week’s newsletter is sponsored by Unblocked.

[Webinar] Can you prove AI is working?

AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.

Join live on Aug 19 (FREE) to learn:

• The 4 metrics to measure the gap where gains leak out before production.

• The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is.

• Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

AI has definitely changed what it means to be a great engineer. Some time ago, you could be considered a great engineer just by being good at a certain programming language and/or specific framework.

Today, a lot of the expected work of software engineers is actually more aligned with being a Tech Lead and a multiplier for others (making everyone around you better). You can read all about this specific shift in this article:

In today’s article, we’re focusing on how you can utilize AI to be more efficient and productive in your day-to-day work, while providing more impact and making everyone around you more effective.

This is an article for paid subscribers, and here is the full index:
- What is an engineering multiplier?
- How to be an effective engineering multiplier?
- There are 3 camps of engineers and engineering leaders when it comes to using AI
- Engineering multipliers use AI to help them be successful, but they don’t delegate their judgment
🔒 This is how you can utilize AI to be a multiplier
🔒 Learn faster using AI
🔒 Think through difficult problems
🔒 Write better code
🔒 Communicate more effectively
🔒 Find relevant information quickly
🔒 Coaching and leading your team
🔒 Make better decisions overall (especially data-driven)
🔒 Automate repetitive work
🔒 Last words

Let’s start!

My Upcoming Book “The Multiplier Mindset” Published by O’Reilly

This article is an adapted version of one of the chapters of my upcoming book called “The Multiplier Mindset”, published by O’Reilly. The book will be published later this year!

Learn more about the book

What is an engineering multiplier?

As tools for development got better, the desired skills for engineers have moved from just pure knowing programming languages and frameworks (expected) to problem-solving abilities and people skills.

It's less about the tasks, but how big an impact you can create. And engineers who can create the biggest impact have the multiplier mindset.

It's the mindset where you focus less on just your pure individual tasks, but you focus on how you can make things better for your whole team, organization, and, of course, the customers (users).

I like the term “Engineering Multiplier” because it’s a mix of “Engineering” and “Force Multiplier”, which fundamentally connects the two together.

Being an engineering multiplier means being someone who amplifies the productivity and effectiveness of the engineers around them, not just focusing on their own output, but elevating the entire team.

An engineering multiplier doesn’t just ask, “What can I build?”, they ask, “How can I make everyone around me more effective?”.

How to be an effective engineering multiplier?

As you can see from the picture above, the 2 main focus areas that are important in the AI era to become an engineering multiplier are:

• Human-related skills and

• Problem-solving abilities

And here is the visual of the most important areas:

In this article, we’ll particularly focus on how to utilize AI to help you in all of these specific skills. Before we get into the details, it’s important to have the proper mindset for utilizing AI.

There are 3 camps of engineers and engineering leaders when it comes to using AI

1. The first camp → everyone who avoids using AI in their day-to-day work

Those are normally more experienced people who have been in the engineering industry for a while and have also seen a lot of shifts in the industry. They are more reluctant to change, and rather stick to what they know and what they are good at.

The problematic part is that the mindset of “It has worked well for me for 15 years, why would I change?” can be really harmful for learning new things and improving your craft.

2. The second camp → everyone who overuses AI in their day-to-day work

Those are normally less experienced engineers, either coming to the industry or they’ve been in the industry for a short while.

Such people normally have a good grasp of AI tools and what’s available out there, but they overly rely on them, resulting in the work being mediocre or, even worse, they don’t even check if the output from the AI tools is aligned with the standards.

Such work can be quite a problem for teams, as it puts a lot of work on reviewers to find out all the problems, which can end up taking a lot more time than it would take if they just do it right from the start.

3. The third camp → everyone who takes a balanced approach with curiosity

This is where you want to be. You don’t just blindly trust the “fancy new tool”, and at the same time, you are very curious to find out how you can improve your own and your team’s workflow with new tools.

You are keen on trying new things out, and at the same time you understand how important good engineering fundamentals and understanding of good engineering practices are.

You like to learn new things all the time, and you look at software development as one of the most fun things to do, because there’s always something new to learn.

Engineering multipliers use AI to help them be successful, but they don’t delegate their judgment

Using different tools that are available to make your day-to-day easier and more productive is what great engineers and engineering leaders do.

This hasn’t changed with AI, it has always been like that. We’ve always looked to automate aspects of our work. AI is a tool like any other, just the difference is that it’s a lot more ambiguous to use.

You get a tool that has so many capabilities, but no real manual on how to use it for your specific case. You need to figure out what works best for you and your work specifically.

At the same time, you shouldn’t just blindly trust these tools, you should verify and ensure they actually make you more productive.

This is how you can utilize AI to be a multiplier

Read more

Read more

This week’s newsletter is sponsored by Unblocked.

[Webinar] Can you prove AI is working?

AI is in your engineering workflow. While the token spend shows it, the throughput doesn’t. The human is very much still in the loop, and that’s a context problem.

Join live on Aug 19 (FREE) to learn:

• The 4 metrics to measure the gap where gains leak out before production.

• The 8 stages of context maturity, the specific walls capping your metrics, and a free tool to pinpoint where your team is.

• Why more MCPs and bigger context windows aren’t enough, and what it takes to get real value from your agents.

Register now

Thanks to Unblocked for sponsoring this newsletter. Let’s get back to this week’s thought!

Intro

Earlier this year, I was in San Francisco talking with different companies, and one of them was Larridin. Funnily, I came right in the middle of their team meeting (sorry guys).

They are building a platform for what many companies are wondering these days → how to measure AI adoption and AI fluency.

Things that especially stood out from our conversations:

• They are a true definition of an AI-native team, with AI being at the core of everything they do.

• They are big advocates of spec-driven development. The spec needs to be almost perfect before they start with the implementation.

• Every engineer owns the feature end-to-end → from creating the spec to implementing it, to ensuring it’s working correctly.

• Ameya Kanitkar, CTO, Larridin, mentioned they also like to work with more junior-level engineers, but they need to leave and breathe AI and always look to improve and get better in this area.

• A great analogy about using AI → You have a fast-driving car right in front of you, why not use it?

I’ve talked with the devs, and also with Ameya, whose insights I am sharing today. In today’s article, we’ll dive into how they are doing spec-driven development at Larridin.

Let’s start!

What is spec-driven development?

There are many different definitions out there, but here is what it means for me:

Spec-driven development is a way of building software where you focus on building a good specification first, and then use AI to implement the project.

There are many ways you can write the spec, for example, Michael Bolin, Codex Tech Lead, uses Notion to create a spec and then asks all the other engineers on the team to take a look and provide comments.

This helps spot any issues beforehand and improves the overall implementation done by the LLMs. To learn Michael’s full process for AI-assisted engineering, read this article:

The popularity behind spec-driven development is increasing

I am seeing spec-driven development as the way to build software used by more and more companies, and it definitely makes sense.

Especially with the cost of tokens just keep increasing, you don’t have the luxury of just infinitely prompting in order to get the desired output (unless you work with unlimited tokens).

With a great spec, you can usually use a lower-tier model and get a very similar output, the reason for that is that the instructions in a great spec are very clear.

So, this is also the workflow that I see many companies use:

• Write a spec (with the help of higher-tier LLMs)

• Build the spec (with the lower-tier LLMs)

Now, let’s get into more details on how Larridin does spec-driven development!

1. Start with a spike first

Ameya mentioned that before they start writing the spec, they prove that the “risky” things work.

In software development, there are a lot of unknowns when you are building things, and it’s impossible to write a complete spec if you are dealing with unknowns.

So, what they do is, they create a spike task to resolve these unknowns of a specific project first.

The goal is not to build a full MVP, it can be a small, ugly, throwaway-quality work. Just enough to answer the question “does this actually work”?

The purpose is not to extend it afterward, as you would normally do with the MVP, but the goal is to remove any technical uncertainty, which, alternatively, would just contaminate the spec with various different options.

Some examples:

• If the API that you’re going to build has 3 edge cases, spike those.

• If your whole system depends on how fast your API is, spike the hot path and measure it.

• If you’re building a new view that has a lot of records in it, prove that the API can return the results fast enough.

And another example that Ameya shared from their work:

We wanted to create a model to measure “AI Fluency”. So we wrote a spike to ensure our core logic works. Once we were happy with the results, the rest of the design followed (queue, monitoring, database, etc.). Spec was simply for ensuring core logic works and is token efficient.

The goal is to stop when you have an answer, not when the code is pretty. If you’re worried about naming variables, functions, and file structure, stop, that’s a sign you’re putting too much thought into implementation details.

2. Promote the spike to reference implementation

Once the spike works, don’t throw it away. It’s now your reference implementation.

This is now a reference that you can point the LLM to and say “I know this pattern works, because here it’s working!”

Ameya believes that this is one of the most underrated things when you’re doing spec-driven development. A working example is worth a lot more than a full page in the spec. That’s how the model stops hallucinating and stops “guessing” the behavior as well.

The reason is that the model can now check the reference and see the approach that has been taken to implement that specific part.

The reference implementation belongs in the repo in a known location. All of the references are in a location: spec/spikes/reference/referenceName.

And also another tip here is to comment on the specific parts that prove the approach, and also add comments to the parts where things are hardcoded, maybe the error handling is missing, or the implementation is not on point.

The more info you give in the codebase, the more accurate the overall implementation by the LLM is going to be.

Ameya believes that a spike without comments can be similarly dangerous as not doing it at all, because the model can just reproduce the wrong parts alongside the right ones.

3. Write the spec

Now that you have the reference implementation with comments, it’s time to write the spec! The spec should be detailed enough to hand to a junior engineer or a small model.

You can and should, of course, use AI to help you write the spec. When you use AI to write the spec, Ameya suggests forcing the model to restate what needs to be done, list any assumptions, and also flag any kind of ambiguity.

So, in case there are any non-handled assumptions and ambiguity left, you can either create a new spike or update the existing one.

Here is also a desired spec structure that they use at Larridin:

• Problem statement at the top

What you’re solving and for whom. One paragraph.

• Non-goals

What this system explicitly will not do. This is where you head off half the overengineering before it starts.

• Assumptions

The details that you have already decided, so the model doesn’t “silently” pick them. Cursor or offset pagination? Lazy loading of components? You need to write all of these down.

• Reference implementation

Link to the spike. Call out (if not already in the comments) which parts are shortcuts, and which parts prove the implementation.

• Architecture

Data model, module boundaries, interfaces, error handling, etc.

• Test plan

What unit, integration, and/or e2e tests are needed and how they need to be done. More on this in the next phase.

Example of a good spec shared by Ameya: Full example of the spec.

And a recommendation he shared:

My recommendation is to write the smallest spec that unambiguously specifies the system. If a section feels like fluff, cut it. If a decision feels obvious, write it down anyway. “Obvious to you” is not the same as “obvious to the model”.

4. Write/adjust the test plan before the implementation plan

Read more

Intro

If you go on any social media these days, you can quite quickly spot AI-generated posts or comments, and it’s really becoming frustrating. As soon as I see that, I immediately go to something else, and I lose a bit of credibility for that person.

And it’s the same with AI-generated emails, messages, articles, or even ADRs and tech specs. While there is certainly a time and place where AI-generated writing makes sense, the problem comes when people expect to read human, thoughtful writing, but instead they get AI-generated text, with no substance.

Imagine asking a question to your colleague, and they just copy & paste an AI-generated response, without even taking the time to edit it. It’s very similar to just submitting a PR full of AI code slop, without taking the time to edit, and putting all the work on reviewers to try finding the issues.

In today’s article, we’ll go through why AI-generated writing is problematic, its use cases + how you can write clearly, develop your own style, and communicate in a way that gets the response you’re looking for.

This is an article for paid subscribers, and here is the full index:
- Why is AI-generated writing problematic?
- Another example, the problem with AI-generated code
- AI is not the issue, the issue is doing “half-done” work
- AI-generated writing is fine if the expectation is aligned with that
- Brevity is more important than ever
🔒 How to write clearly?
🔒 Develop your style of writing
🔒 Know your audience
🔒 Different tips and tools that can help you
🔒 Last words

Let’s start!

Why is AI-generated writing problematic?

As mentioned a bit in the intro, it’s not that AI-generated text is problematic by default, the problematic part is the misalignment between expectations.

Here is a good example:

You go to the cinema to watch a new movie that has been advertised as the “next must-see movie”, and you have high expectations of it. Great story, thoughtful scripts, great cast, etc. You are excited.

But then the movie starts, and things go sideways quickly. Generic story, generic graphics, generic cast, etc. The movie was actually AI-generated. What are your thoughts?

You are not happy about it because your expectations were different.

And it’s very similar with AI-generated emails, messages, blog posts, etc. You get a bad taste in your mouth if you expected to read thoughtful writing, while in reality you read AI-generated writing.

Let’s go to another example that I regularly see being problematic, especially for engineers who are reviewing code.

Another example, the problem with AI-generated code

What I am seeing and also hearing happening regularly, especially with less experienced engineers, is the following:

They are assigned a task, and they use a certain AI coding tool, use their agent mode to finish the task, and then they don’t go the extra mile to actually understand what has been changed and ensure the changes are made within the guidelines of the codebase.

They open the PR, and because they didn’t actually take the time to read and edit the code, this puts a lot of pressure on reviewers to find all the mistakes and completely shifts the work on them.

There may be a lot of comments on PRs, and it takes a lot of time to review correctly. And even in some cases, engineers give up and just approve the PR, which makes things a lot worse in the long run.

For me, personally, if I see a PR opened full of AI-generated slop, that particular engineer would lose a lot of credibility in my eyes. Or even worse, if they mention that the mistake is there “because of AI”.

Every good engineer should know and realize that overall accountability is on them to ensure that good-quality code is delivered and not look to shift the accountability elsewhere.

Of course, I get it, we all make mistakes, but at the end of the day, submitting a full PR of AI-generated slop or blaming AI for a mistake is not a good look.

AI is not the issue, the issue is doing “half-done” work

This is the core message that I want to get across in this article.

As soon as you send a message or open a PR where you just copy & paste the first AI-generated output and didn’t actually take the time to ensure it’s done to the correct quality, you lose credibility.

Even if you don’t receive the feedback directly, you are going to be perceived differently, and if you do this for a longer amount of time, you’ll end up having a bad reputation, which can be quite problematic, especially these days with a lot of layoffs happening across the industry.

So, always ask yourself, am I doing the work that is perceived to be good quality? Or am I just doing the minimal effort work?

If you’re doing the second, it’s time to really reconsider your priorities. Your reputation is one of the most important things, and how people perceive you really goes a long way.

Now, let’s get to an important point, where AI generated writing is totally fine.

AI-generated writing is fine if the expectation is aligned with that

There are definitely use cases where AI-generated text is fine, like, for example, if everyone is aligned that the tech spec or ADR will be fully AI-generated, and you keep improving it with prompts.

Additionally, if there is a clear PR template prepared, where everyone generates the description with AI, that’s totally fine as well.

But the problem comes when you’re trying to share AI-generated writing masked as your own. Like responding to PR review comments with AI, or responding to Slack messages with purely AI-generated text.

Or even writing full blog posts, articles with AI, that’s fully unacceptable from my perspective. Maybe some people would read it, but me, I won’t.

That’s also the reason why all the articles on this newsletter are going to be written in my style, which I developed in close to 4 years of writing online.

Now that we understand where AI-generated text is fine versus not, let’s go through the importance of clear writing and brevity.

Brevity is more important than ever

What brevity means is to use the right amount of words (no fluff) to communicate an idea clearly. It’s being concise and clear with your written communication.

It means that you can put yourself in the shoes of your reader(s) and write it in a way that resonates with them.

Brevity is a sign of respect for the reader’s time.

This is the post that I posted on LinkedIn earlier this week, which shares an example of brevity (from 2014):

In this situation, it worked. Niraj got the response from Evan, which resulted in a positive one.

What’s important to mention here is that I wouldn’t bet on sending a cold email like that in 2026 and expect to get a similar response.

A lot of people, especially recruiters or hiring managers, have already seen this before (as it’s been quite a popular picture shared across social media in recent years). And it’s a bit of a cliché.

But what’s important is that it worked for Niraj back in 2014. And that’s how you need to think about writing.

Ask yourself: How can I write in a way that would get me the desired response?

This is the art of brevity. Knowing who your audience is and how to frame it in a way that would resonate with them the most.

Let me share some examples and tips for clear written communication next.

How to write clearly?

Read more

Read more