DEV Community: Roman Nikolaev

Nothing Is Sacred: Rethinking How Engineering Teams Work

Roman Nikolaev — Mon, 30 Mar 2026 10:58:00 +0000

Industry is moving at breakneck speed.

In three years, we went from better auto-complete to autonomous agents. The software engineering landscape is rapidly changing.

Don’t get me wrong. It also happened before.

I started programming in BASIC when programs were loaded from compact cassettes. Ten years later, I used a visual IDE to create graphical user interface applications. Then came web applications. Then the smartphone apps market. Virtualization. Cloud. And then GenAI.

Maybe I missed a few things, but the point is that in the span of one person’s career — barely 40 years — the tools have fundamentally changed. The waves of change come more and more frequently.

This creates great pressure on software engineering organizations to adapt. The organizations that don’t change their ways of working will be left behind.

There is a discussion now about agile becoming obsolete in the fast-moving environment.

I disagree.

Agile Still Matters

The agile way of thinking is as important as ever before. For me, agile is not a framework. It is a way of thinking.

One of the agile values is continuous learning, and it is precisely what teams need to do now. At a time of disruption, the focus of learning changes from incremental improvement to rethinking processes and tools from scratch.

Nothing is sacred.

Engineering leaders should stop treating inherited best practices as defaults and start treating them as reversible experiments.

What is the role of code reviews?
Does the team need to be aligned over every technical decision?
Can developers design and designers ship code?
What is the role of a product owner?
Do we need estimates?
Is rewriting from scratch still a terrible idea?

There are many, many more.

But what if we try and fail? For example, if we relax our code review practices, then we get an outage.

The concern is valid, but if we don’t try, we will never know.

To fully benefit from new tools, we have to embrace experimentation.

A Simple Experiment Framework

I propose following these steps:

1. Identify a bottleneck

Find a handoff, a meeting, or a step that involves additional people.

2. Define an experiment

What if you remove the handoff, cancel a meeting, or move the decision-making to the person who does the work?

3. Set success and failure metrics

Has quality gone down? Do QA and users report more defects? Is team satisfaction down? Is the number of PRs up? Has the number of bugs decreased?

4. Timebox it

Let’s do it for a month. If it’s successful, continue for another month.

5. Monitor it

Follow the metrics. If something starts to go wrong, cancel the experiment.

6. Conclude

Check after the timebox is over. Decide if you want to continue the experiment, roll it back, or make it permanent.

Example 1: Meetings

Daily meeting breaks team focus.

We move the meeting to an async report in Slack. Identified blockers are addressed in smaller groups.

We measure PR throughput and team satisfaction in retrospectives before and during the experiment. We establish the baseline and check against it every two weeks.

Run the experiment for two weeks first. If no red flags appear, continue for another two weeks.

Check PR throughput weekly and team satisfaction every two weeks during retrospectives. If there are red flags, we cancel and return to the previous model.

After one month, we debrief with the whole team and decide together if we keep the new way of working or stop.

Example 2: Process

The team’s UX designer is overloaded with work and cannot concentrate on bigger things because of constant smaller requests.

Empower developers to propose possible solutions to the designer. The designer only needs to approve.

We evaluate whether the designer can concentrate better and move forward on strategic work. How many times per week do developers propose their own solutions instead of asking for design clarification? How many of these solutions are approved?

It is a low-risk experiment and requires a culture shift. We run this for two months with monthly checkpoints.

Interview the designer after one month. Count the number of times the developers took the initiative.

Decide after two months if the approach works or if something else needs to be done.

Example 3: AI-Native Ways of Working

Code reviews are a bottleneck. Senior developers context-switch multiple times a day to review PRs, and authors wait hours or days for feedback.

We introduce an AI coding agent as the first reviewer. It checks for bugs, security issues, style violations, and adherence to team conventions. Human reviewers focus only on what the AI flags or on changes to critical paths such as payments, auth, and data migrations.

We measure time from PR opened to PR merged. We track production incidents before and during the experiment. We survey reviewers on whether they feel they can focus on deeper work instead of routine review comments.

Run for one month with biweekly checkpoints. If production incidents spike, we stop immediately.

Check production incident rate and PR merge time weekly. Gather reviewer feedback at each biweekly checkpoint. Any quality degradation beyond the baseline means we cancel and return to full human reviews.

After one month, debrief with the whole team. Decide together if we keep the AI-first review process, stop it, or make it permanent.

Other Example I’ve Lived Through

Below are a few more changes I lived through:

Dropping manual regression testing
Replacing sprint planning and estimation with goal alignment
Introducing non-blocking code reviews
Replacing synchronous UI walkthroughs with Loom videos
Introducing RFCs for asynchronous planning

Some experiments failed. But every successful experiment led to the organization getting a little better.

These small things compound and lead to a categorical jump in the team’s performance.

The Real Risk

Changing well-established best practices can feel scary. But the worst thing that can happen is that the experiment fails and we return to where we started.

Inaction, on the other hand, guarantees that we are left behind in a quickly changing environment.

Changing well-established best practices feels scary. But the worst thing that can happen is that the experiment fails and you return to where you started. That’s it.

Inaction has no such safety net. It guarantees you fall behind.

Being truly agile — beyond the frameworks, the dogmas, and the best practices from the past — is no longer good to have. It is how you survive.

Originally posted at: https://highimpactengineering.substack.com/p/nothing-is-sacred-rethinking-how?r=36g804

Subscribe for weekly articles like this at https://highimpactengineering.substack.com/

Nothing Is Sacred: Rethinking How Engineering Teams Work

Roman Nikolaev — Mon, 30 Mar 2026 10:58:00 +0000

Industry is moving at breakneck speed.

In three years, we went from better auto-complete to autonomous agents. The software engineering landscape is rapidly changing.

Don’t get me wrong. It also happened before.

This creates great pressure on software engineering organizations to adapt. The organizations that don’t change their ways of working will be left behind.

There is a discussion now about agile becoming obsolete in the fast-moving environment.

I disagree.

Agile Still Matters

The agile way of thinking is as important as ever before. For me, agile is not a framework. It is a way of thinking.

Nothing is sacred.

Engineering leaders should stop treating inherited best practices as defaults and start treating them as reversible experiments.

What is the role of code reviews?
Does the team need to be aligned over every technical decision?
Can developers design and designers ship code?
What is the role of a product owner?
Do we need estimates?
Is rewriting from scratch still a terrible idea?

There are many, many more.

But what if we try and fail? For example, if we relax our code review practices, then we get an outage.

The concern is valid, but if we don’t try, we will never know.

To fully benefit from new tools, we have to embrace experimentation.

A Simple Experiment Framework

I propose following these steps:

1. Identify a bottleneck

Find a handoff, a meeting, or a step that involves additional people.

2. Define an experiment

What if you remove the handoff, cancel a meeting, or move the decision-making to the person who does the work?

3. Set success and failure metrics

Has quality gone down? Do QA and users report more defects? Is team satisfaction down? Is the number of PRs up? Has the number of bugs decreased?

4. Timebox it

Let’s do it for a month. If it’s successful, continue for another month.

5. Monitor it

Follow the metrics. If something starts to go wrong, cancel the experiment.

6. Conclude

Check after the timebox is over. Decide if you want to continue the experiment, roll it back, or make it permanent.

Example 1: Meetings

Daily meeting breaks team focus.

We move the meeting to an async report in Slack. Identified blockers are addressed in smaller groups.

We measure PR throughput and team satisfaction in retrospectives before and during the experiment. We establish the baseline and check against it every two weeks.

Run the experiment for two weeks first. If no red flags appear, continue for another two weeks.

Check PR throughput weekly and team satisfaction every two weeks during retrospectives. If there are red flags, we cancel and return to the previous model.

After one month, we debrief with the whole team and decide together if we keep the new way of working or stop.

Example 2: Process

The team’s UX designer is overloaded with work and cannot concentrate on bigger things because of constant smaller requests.

Empower developers to propose possible solutions to the designer. The designer only needs to approve.

It is a low-risk experiment and requires a culture shift. We run this for two months with monthly checkpoints.

Interview the designer after one month. Count the number of times the developers took the initiative.

Decide after two months if the approach works or if something else needs to be done.

Example 3: AI-Native Ways of Working

Code reviews are a bottleneck. Senior developers context-switch multiple times a day to review PRs, and authors wait hours or days for feedback.

Run for one month with biweekly checkpoints. If production incidents spike, we stop immediately.

After one month, debrief with the whole team. Decide together if we keep the AI-first review process, stop it, or make it permanent.

Other Example I’ve Lived Through

Below are a few more changes I lived through:

Dropping manual regression testing
Replacing sprint planning and estimation with goal alignment
Introducing non-blocking code reviews
Replacing synchronous UI walkthroughs with Loom videos
Introducing RFCs for asynchronous planning

Some experiments failed. But every successful experiment led to the organization getting a little better.

These small things compound and lead to a categorical jump in the team’s performance.

The Real Risk

Changing well-established best practices can feel scary. But the worst thing that can happen is that the experiment fails and we return to where we started.

Inaction, on the other hand, guarantees that we are left behind in a quickly changing environment.

Changing well-established best practices feels scary. But the worst thing that can happen is that the experiment fails and you return to where you started. That’s it.

Inaction has no such safety net. It guarantees you fall behind.

Being truly agile — beyond the frameworks, the dogmas, and the best practices from the past — is no longer good to have. It is how you survive.

Originally posted at: https://highimpactengineering.substack.com/p/nothing-is-sacred-rethinking-how?r=36g804

Subscribe for weekly articles like this at https://highimpactengineering.substack.com/

Nothing Is Sacred: Rethinking How Engineering Teams Work

Roman Nikolaev — Mon, 30 Mar 2026 10:58:00 +0000

Industry is moving at breakneck speed.

In three years, we went from better auto-complete to autonomous agents. The software engineering landscape is rapidly changing.

Don’t get me wrong. It also happened before.

This creates great pressure on software engineering organizations to adapt. The organizations that don’t change their ways of working will be left behind.

There is a discussion now about agile becoming obsolete in the fast-moving environment.

I disagree.

Agile Still Matters

The agile way of thinking is as important as ever before. For me, agile is not a framework. It is a way of thinking.

Nothing is sacred.

Engineering leaders should stop treating inherited best practices as defaults and start treating them as reversible experiments.

What is the role of code reviews?
Does the team need to be aligned over every technical decision?
Can developers design and designers ship code?
What is the role of a product owner?
Do we need estimates?
Is rewriting from scratch still a terrible idea?

There are many, many more.

But what if we try and fail? For example, if we relax our code review practices, then we get an outage.

The concern is valid, but if we don’t try, we will never know.

To fully benefit from new tools, we have to embrace experimentation.

A Simple Experiment Framework

I propose following these steps:

1. Identify a bottleneck

Find a handoff, a meeting, or a step that involves additional people.

2. Define an experiment

What if you remove the handoff, cancel a meeting, or move the decision-making to the person who does the work?

3. Set success and failure metrics

Has quality gone down? Do QA and users report more defects? Is team satisfaction down? Is the number of PRs up? Has the number of bugs decreased?

4. Timebox it

Let’s do it for a month. If it’s successful, continue for another month.

5. Monitor it

Follow the metrics. If something starts to go wrong, cancel the experiment.

6. Conclude

Check after the timebox is over. Decide if you want to continue the experiment, roll it back, or make it permanent.

Example 1: Meetings

Daily meeting breaks team focus.

We move the meeting to an async report in Slack. Identified blockers are addressed in smaller groups.

We measure PR throughput and team satisfaction in retrospectives before and during the experiment. We establish the baseline and check against it every two weeks.

Run the experiment for two weeks first. If no red flags appear, continue for another two weeks.

Check PR throughput weekly and team satisfaction every two weeks during retrospectives. If there are red flags, we cancel and return to the previous model.

After one month, we debrief with the whole team and decide together if we keep the new way of working or stop.

Example 2: Process

The team’s UX designer is overloaded with work and cannot concentrate on bigger things because of constant smaller requests.

Empower developers to propose possible solutions to the designer. The designer only needs to approve.

It is a low-risk experiment and requires a culture shift. We run this for two months with monthly checkpoints.

Interview the designer after one month. Count the number of times the developers took the initiative.

Decide after two months if the approach works or if something else needs to be done.

Example 3: AI-Native Ways of Working

Code reviews are a bottleneck. Senior developers context-switch multiple times a day to review PRs, and authors wait hours or days for feedback.

Run for one month with biweekly checkpoints. If production incidents spike, we stop immediately.

After one month, debrief with the whole team. Decide together if we keep the AI-first review process, stop it, or make it permanent.

Other Example I’ve Lived Through

Below are a few more changes I lived through:

Dropping manual regression testing
Replacing sprint planning and estimation with goal alignment
Introducing non-blocking code reviews
Replacing synchronous UI walkthroughs with Loom videos
Introducing RFCs for asynchronous planning

Some experiments failed. But every successful experiment led to the organization getting a little better.

These small things compound and lead to a categorical jump in the team’s performance.

The Real Risk

Changing well-established best practices can feel scary. But the worst thing that can happen is that the experiment fails and we return to where we started.

Inaction, on the other hand, guarantees that we are left behind in a quickly changing environment.

Changing well-established best practices feels scary. But the worst thing that can happen is that the experiment fails and you return to where you started. That’s it.

Inaction has no such safety net. It guarantees you fall behind.

Being truly agile — beyond the frameworks, the dogmas, and the best practices from the past — is no longer good to have. It is how you survive.

Originally posted at: https://highimpactengineering.substack.com/p/nothing-is-sacred-rethinking-how?r=36g804

Subscribe for weekly articles like this at https://highimpactengineering.substack.com/

Async by Default

Roman Nikolaev — Mon, 15 Dec 2025 18:51:51 +0000

My team is 90% remote. It took us a few years to figure out when to meet and when to write.

Industry-wide studies say that developers spend only a small fraction of their time writing code. The rest goes into reviewing code, writing documentation, communicating on different channels, and meetings.

All these activities fall into two buckets: working alone and working together.

Both are important.

Individual work is when the code and consequently value is produced.

Working together with others supports individual work and does not usually produce value directly.

However, collaboration is unavoidable in organizations larger than one person.

The real question: “How to find the right balance between collaborating with others and individual work?”

The Challenge

Striking the balance is often a challenge. On one side of the spectrum are technical organizations drowning in meetings. Developers don’t have time to code, and essential technical work moves at a snail’s pace.

The other side of the spectrum is very anti-meeting. This creates its own problems. Developers become disconnected from the business and from each other. Misalignment grows, technical debt accumulates faster than anyone expects, team cohesion and spirit take a hit.

Async as the Default

My preferred way for balancing collaboration and individual work is by moving some of the collaboration to asynchronous mode. For example, instead of having a status update meeting, everyone writes an update to the team’s Slack channel.

Another example is turning a face-to-face architecture design meeting into an asynchronous RFC review. (You can read more about using internal RFCs here: https://highimpactengineering.substack.com/p/the-illusion-of-shared-understanding)

A Spectrum: From Easy to Hard to Do Async

Let’s go from the least difficult activities to do asynchronously to the most difficult.

1. Informing

All kinds of reports and status updates can be done asynchronously using Slack, email, or written memos. An additional benefit is that unlike face-to-face updates, written updates can be easily shared.

2. Problem Solving

Many technical problems are better handled async.

When someone needs input, feedback, or review, they can share a proposal or prototype with the team. People contribute their thoughts on their own time.

This reduces interruptions and leads to more thoughtful contributions.

3. Decision-making

Decisions don’t always require a meeting.

If the facts are clear and consensus isn’t critical, async decision-making works well.

But when ambiguity is high—or you need explicit group buy-in—a synchronous conversation is worth the time.

This is one of the key judgment calls for engineering leads.

4. Innovating

Innovating can be done asynchronously but in my experience the best ideas are born in real-time interactions such as workshops and hackathons.

When the goal is creativity, synchronous time has a magic that async cannot fully replace.

5. Building Personal Connections

Building personal connections does not work well through chats and email, but thrives when people meet in the same place. This is why offsites, in-person gatherings, and even regular face-to-face calls help teams build trust and ultimately work better together.

A two-day offsite can build more trust than months of Slack messages.

How We Apply This

Depending on where you are on the meeting-heavy to anti-meeting spectrum, different changes might be needed. In my practice I have been on both sides. After iterating for a while I found a few strategies that work well.

Split planning into two parts

One of the biggest wins has been splitting planning into two parts. Feature or large increment kick-offs are held face-to-face.

Detailed technical planning is done primarily asynchronously using RFCs.

This split gives the team shared understanding of the bigger picture without going into details that would be premature. We innovate, decide, and connect during the kickoff—and then individuals do the deeper planning work on their own.

Dailies: keep or skip

As mentioned earlier, status updates are the easiest to do asynchronously. However, for remote teams a camera-on daily meeting might be essential.

For a developer the daily meeting may be the only touch point with the rest of the team. It helps team members stay connected to each other.

In this case daily serves a double purpose: both informing and connecting.

For teams that work primarily on-site, I believe the daily can be moved to async—people only meet to address blockers.

Async UI design reviews

Another thing we do primarily asynchronously is UI design reviews. We use screen recordings, sometimes with voice-over. Review requests have deadlines and assign reviewers.

This not only saves time but produces better results—people have time to digest the proposal.

Finding Your Balance

Implementing these strategies helped my team move faster while staying connected to each other and to the business.

If you like the idea, look at your collaboration patterns.

Ask:

Does this activity really need to be synchronous?

Does the team feel sufficiently connected to each other?

Would more face time help? With each other? With stakeholders?

Where is async clarity missing?

Where is synchronous energy missing?

Getting this balance right can dramatically improve a team’s velocity, alignment, and well-being.

Thank you for reading.

This is the second essay in the series on communication in technical teams. If you’d like to receive new essays weekly, subscribe to High-Impact Engineering.

Originally published at High-Impact Engineering.

The Illusion of Shared Understanding

Roman Nikolaev — Wed, 10 Dec 2025 20:50:10 +0000

Have you ever returned from vacation to find the project you entrusted to your team completely off track?

I have — and that experience taught me one of the most important lessons of my engineering career. In this article I’ll share why teams often believe they’re aligned when they’re not, and how a simple RFC process can prevent months of wasted work.

This happened years ago when I worked as a lead in a software engineering team.

I had started working on a big, complex feature that was supposed to be ready in two months. However, my vacation was approaching and I would be away for one month.

To stay on schedule I asked two engineers from my team to continue the development. I explained what the feature would be doing and how I planned to implement it. We had a couple of sessions where we went through the target architecture in detail, including drawing diagrams on the whiteboard. Developers said that everything was clear and they would be able to finish it when I was away.

One month later, when I returned from my summer break, the feature was almost ready.

Or so I thought until I looked at the code.

I was shocked to find that the feature was addressing only a small special case. Nothing else worked.

What followed was one of the most dramatic sprints in my career. I worked evenings and weekends, on the plane and on the bus. In the end I missed the deadline anyway, however not by much.

I felt very upset, but I didn’t have anyone else to blame but myself. I failed to recognize that we only had the illusion of shared understanding. We thought we were in agreement when in fact we had totally different mental models of what needed to be done.

Similar situations, maybe not that dramatic, happened many times throughout my career, so I started to see the pattern and look for a solution. I needed a way to make mental models visible — not just assumed. That’s when I stumbled on the idea of internal RFCs.

RFC stands for request for comments. It is a document describing a solution which is shared within a team, organization, or publicly in order to receive feedback.

I knew RFCs before from open-source projects, where they are widely used to facilitate decision-making within the OSS community. However, I never thought of using RFCs internally in an organization.

The RFC approach has several advantages over verbal alignment. First of all, it is more precise. The need to write forces the author to clearly structure their thoughts into a coherent logical narrative. While writing, the author has time to examine their proposed solution from different angles and clearly see pros and cons of it.

Another advantage of the document over verbal explanation is that a well-written RFC leaves little room for misinterpretation. It can include diagrams, examples, or calculations to illustrate and support the idea.

Finally, we can return and reread the RFC later. Human memory is unreliable; already after a day, details that were crystal clear in one’s mind start to get blurry. When these details are written down, it is easy to review them at any time.

Despite these advantages, introducing RFCs can still meet resistance. The most common objection is that writing proposals is “a waste of time” compared to writing code.

A good way to overcome this is to introduce RFCs as a timeboxed experiment.

Try it for a month, then debrief as a team and decide whether the practice is worth continuing. A short experiment lowers the psychological barrier to change.

During that first month, it helps if you write the first few RFCs yourself.

This models the behavior you want to see and keeps the initial bar low. Ask the team to comment — not write — which is a much easier first step for them.

It also helps to bring one or two formal or informal leaders on board early. If people who have influence participate in RFC discussions, others will follow naturally.

Cultural changes die when leaders propose them but don’t participate. If even the champions of the idea don’t write or review RFCs, the team will quickly abandon the practice.

To start RFC adoption you will need a template that your team can start using right away. There are a lot of options on the internet to choose from, or you can use my template, which has been working well for me and my team.

The template I use includes two main parts: header and body.

The header has the following information:

RFC name. It is simply the name of the document in Git or, for example, in Confluence.

Owner. Author of the RFC. If the team is small and the RFC is not shared outside of the team, this field can be skipped.

Date. Creation date. Good to have for bookkeeping and later reference.

Status. One of the following: Work in Progress, In Review, Approved, Obsolete.

Approvers’ names and their approval statuses. The status can be one of three: Not Approved, Approved, Declined.

Below the header is the body of the document. The body consists of two sections.

Background. Explains the business or technical context behind the change — why the proposal exists and what problem it solves.

Proposal. Describes the solution. It can include text, diagrams, examples, images, or any other media that helps convey the idea clearly.

You can find the full template here.

That is all there is to it. As you can see, the template is very simple. Now let’s discuss when and how to use it.

To make this more tangible, let’s look at a few concrete work situations where RFCs are useful.

Imagine a team member raises a technical issue during the daily standup. The problem is clearly too complex to solve in a quick discussion. Instead of trying to resolve it immediately or scheduling yet another meeting, you could ask the team to write their proposals as RFCs and review them asynchronously. This gives everyone time to think, compare solutions, and come back with clearer reasoning.

Another typical situation is when the team is about to start working on some complex new functionality. Instead of jumping directly into the coding, you could suggest that someone on the team take time to do research and write a detailed RFC describing the technical approach. Writing and reviewing the proposal within the team will help pick the right approach and at the same time ensure that everyone on the team has the same understanding of the work ahead.

When I look back at the time I left on vacation and handed the feature over to the team, I really wish I had written an RFC. I’m sure the engineers would have executed the work exactly as intended.

We learned the lesson, and now RFCs are an integral part of our engineering process. They help us create better technical solutions, stay aligned on the architectural vision, and spread knowledge across the team.

This is the first in a series on building clarity into how teams work. If you found it useful, consider subscribing to High-Impact Engineering for new essays weekly.

Originally published at https://highimpactengineering.substack.com/p/the-illusion-of-shared-understanding?r=36g804