This is exactly where Architecture Decision Records (ADRs) come in. They capture and preserve the context, rationale, and trade-offs for the most critical decisions you make, ensuring knowledge isn’t lost and that your team can move forward confidently. By writing architecture decisions down, you create a durable knowledge asset that will outlive the project itself.

In this article, we’ll explore how documenting architecture decisions can transform your engineering organization from one that’s plagued by constant rehashing of old debates to one that runs like a well-oiled, knowledge-sharing machine.

What is Architecture Decision Record?

An Architecture Decision Record (ADR) is a concise document that captures an important design choice and the context around it. Think of it as a single-page summary of a pivotal decision: the motivation, the alternatives considered, the trade-offs, and the consequences. Each ADR is typically stored in a repository, creating a living log of how and why your architecture evolved.

Instead of relying on memory or long-forgotten meeting notes, you can pull up an ADR to see exactly what led your team to adopt technology X or design pattern Y.

Why Documenting Architecture Decisions Matters

1. A Single Source of Truth

Think of ADRs as a time capsule for your architecture’s evolution. They provide a single source of truth that any current - or future - team member can consult. No more searching through Slack threads or email chains to figure out why something was done a certain way.

2. Better Onboarding and Cross-Team Collaboration

ADRs remove guesswork for new hires or teams that need to integrate with your system. When decisions are explicitly documented, teams can quickly grasp design intentions, constraints, and trade-offs. This accelerates onboarding and prevents siloed knowledge.

3. Encourage Thoughtful, Data-Driven Decisions

Writing an ADR forces you to articulate your thought process. You must consider alternatives, articulate the rationale, and understand the implications. This type of deliberate, data-driven approach elevates the quality of architectural discussions.

4. Simplify Architecture Evolution

Architectures evolve and that’s normal. When you deprecate, change, or supersede a decision, referencing and updating the original ADR clarifies the historical context. It’s a lightweight but powerful way to manage the living, breathing entity that is your system architecture.

A Simple ADR Template

Below is a straightforward example (based on this template) you can start using today. Keep it simple. The goal is to document the most important aspects of each architectural decision - no need to write anything elaborate and long as this could discourage from writing ADRs in the long run.

## Title

<Short title describing what this ADR is about>

## Status

<Accepted | Superseded by ADR-xx>

## Date

<Date>

## Context

<Describe the nature of the problem that requires a decision and all relevant context around it.>

## Decision

<Describe briefly the decision that was made.>

## Rationale

<Explain the reasoning behind the decision and its trade-offs and why it is consider the preferred option.>

## Implications

<Describe the side-effects of this decision, both technical and not-technical one. Include both positive and negative implications>

## Alternatives Considered

<Describe any alternative solutions that were considered as a potential solution and why they were not chosen.>

## References

<Optional. Include any links to resources that influenced the decision or might be helpful in understanding the subject of the decision in depth>

Example: Migrating from Synchronous HTTP API to Kafka

Here’s a fictional - but very plausible - example you might see in an Architecture Decision Repository.

## Title

Migrating from Synchronous HTTP API to Kafka

## Status

Accepted

## Date

2025-03-10

## Context

Our microservices currently communicate via synchronous HTTP APIs, causing latency issues and occasional disruptions when one service is unavailable. Also, the cost to handle the entire traffic is very high. Most of the communication, especially reads, don't require synchronous flow. We also anticipate a need to handle significantly higher  request volumes in the near future. To increase resiliency, scalability and cost-efficiency, an asynchronous communication would be preferred.

## Decision

We will transition from synchronous HTTP API calls to a Kafka-based event-driven architecture for communication between our microservices.

## Rationale

- Scalability: Kafka’s event-driven model allows simple horizontal scaling of consumers, which is critical for our anticipated traffic growth and is also very cost-efficient.

- Resilience: Asynchronous messaging decouples microservices, so one service’s downtime doesn’t cascade throughout the system, which is especially important for writes/commands. That will allow us to take advantage of Saga pattern.

- Cost-efficiency: A simple proof of concept indicates that just 3 Kafka consumers can read the equivalent amount of data as 25 Sidekiq workers reading from HTTP API. Also, it implies that we will be able to scale down web workers of the upstream service by 40% as we won't be reading this data from the HTP API.

## Implications

- Operational Overhead: We need to maintain a Kafka cluster, which introduces new complexity for monitoring, alerting, and administration. Amazon MSK service can be a great solution here.

- Kafka Learning Curve: Engineers will need to gain familiarity with event-driven design patterns and Kafka itself.

- Deployment and Migration Plan: We’ll roll out event streams incrementally to avoid a “big bang” migration. Secondary microservices will be adapted first, followed by the more critical ones.

## Alternatives Considered

1. Continue with Synchronous HTTP: Would be simpler to maintain, but scalability, resiliency and cost-efficiency trade-offs are not acceptable in the long run.

2. Use a Different Message Broker (e.g.RabbitMQ): While viable, Kafka’s persistence and proven track record with large-scale event processing made it more appealing.

## References

- [Kafka Documentation](https://kafka.apache.org/documentation/)
- [Event-Driven Architecture Patterns](https://www.confluent.io/learn/event-driven-architecture/)

When to Write (and When Not to Write) an ADR

ADRs are meant to capture key decisions that have long-term implications for your system or organization. If a decision introduces a new dependency, alters fundamental data flows, or significantly affects architecture and team processes, it likely requires an ADR.

On the other hand, minor decisions - like tweaking a library version or refactoring a single function usually don’t need an official record.

Use your judgment: if it’s significant enough that others might question later or that will be difficult to undo, document it. Otherwise, don’t let the process become an administrative burden.

Recommendations for Organizing ADRs

Once you start adopting ADRs, having a clear organizational strategy is essential. Many teams keep their ADRs in a dedicated folder within their source control (like docs/adrs), ensuring everything is versioned alongside the code.

For those who prefer a more dynamic knowledge base, solutions like Notion can be excellent for storing and collaborating on ADRs. You can create a Notion database, tag each ADR with relevant topics (e.g., “Security,” “Scalability,” “Data Layer”), and link out to related discussions or artifacts.

The key is to pick a system that fits your team’s workflow - something both discoverable and easy to maintain. By keeping ADRs well-organized and centrally accessible, you amplify their impact and make it far more likely your team will actually reference and update them over time.

Wrapping up

ADRs are not meant to add bureaucratic overhead. Rather, they serve as lightweight documentation that captures the heart of each major technical decision - protecting your team from knowledge loss, rehashing old arguments, and misalignments. By inroducing ADRs into your engineering culture, you will enable stronger collaboration, make more informed decisions, and onboard new team members with ease.

The next time your architecture evolves, don’t leave your decisions to chance or memory. Make them transparent, searchable, and future-proof by documenting them in an Architecture Decision Record. You’ll thank yourself the next time someone inevitably asks, “Wait, why did we choose this again?”

In this article, we’ll explore who product engineers are, what sets them apart, how they can make 10x impact in ways that goes beyond the number of submitted pull requests, and how you can become one.

Who is a Product Engineer?

A product engineer is a hybrid between a software engineer and a product manager, wearing multiple hats to ensure that technology aligns with user needs and business strategy. While traditionally developers mostly focus on how to build a solution, product engineers equally consider the why: user needs, business context, measurable outcomes and ROI.

Rather than just checking off backlog items, a product engineer will:

• Talk to users or participate in customer support calls to uncover root problems.

• Strategically decide which features to prioritize for maximum impact.

• Own a feature end-to-end: from the user research and a first prototype, all the way to release and post-launch analytics.

What Sets Product Engineers Apart

If you’ve spent any time in traditional software engineering roles, with a hard separation between software engineers and product managers, you’ll notice some important distinctions:

1. User-Centric Mindset
   Product engineers care deeply about user experience. They frequently ask, “Does this feature actually solve a user’s real problem?” instead of just “Is the solution well-architected?” Technical design obviously matters, but delivering impactful features is what matters the most.

2. Strategic Vision
   Product engineers go beyond tech excellence and understand that solid engineering is just the beginning. They tie their work to business goals, be it improving onboarding experience, boosting ARR, or reducing churn.

3. Holistic Problem-Solving
   Beyond code and architecture, product engineers factor in design decisions, market research, and even psychological triggers that influence user behavior. They connect the dots across design, marketing, support, and engineering.

4. Cross-Functional Communication
   Because the scope of the role is so broad, product engineers excel at collaborating and communication with different stakeholders. They can jump into design discussions, help marketing refine a launch plan, or talk to senior leadership about key product metrics.

5. Outcome-Driven Prioritization
   Instead of getting stuck in perfecting the design to prepare for the scale that is nowhere in sight or delivering features for the sake of delivering more, product engineers consistently ask: “What’s the smallest thing we can build that will bring value to our customers?”

The 10x Impact: Outcomes Over Output

For years, the mythical 10x developer was the one who solved tickets at massive speed, regardless of their impact, as if they were working in a feature factory. But the 10x product engineer drives impact across the entire product cycle.

Here’s what it looks like in practice:

• Identifying High-Leverage Opportunities
  Maybe there’s a complicated checkout flow causing customers to abandon their carts. While a 10x developer might optimize query performance in just a few minutes, a product engineer sees a greater opportunity in simplifying the checkout flow to immediately boost conversion rates.

• Rapid Iteration & Learning
  They ship small, test quickly, gather feedback, and iterate. Reducing time-to-market for impactful features can produce a ripple effect on customer satisfaction and drive the increase of revenue.

• Proactive Problem-Solving
  Product engineers don’t wait for someone to create a Jira ticket to report a bug. They anticipate needs by talking to users, analyzing metrics, and staying aligned with product goals. This forward-thinking approach often prevents big problems before they even surface.

• Data-Informed Decision-Making
  Instead of celebrating a launch of a new microservice, a product engineer measures success through user adoption, churn reduction, or revenue growth. This clarity on outcomes aligns engineering efforts with the company’s bottom line.

The result? A 10x product engineer might not write 10x more code or solve 10x more Jira tickets - but they’ll often deliver 10x impact because they solve the right problems in the most efficient way.

Becoming a Product Engineer

People often transition into product engineering from two primary paths: software development or product management. While both are valid, it’s generally easier for an engineer to pick up product skills than for a Product Manager to dive deep into software engineering.

Product Management is rather a complementary skill for senior developers, and learning enough to make a significant impact won’t necessarily take a massive amount of time.

For Product Managers, software engineering will likely be a completely new skill that will take years to learn. Some PMs might argue with that statement, especially the ones who know how to use Windsurf or Cursor, but we need to get this straight - while AI can be very helpful for generating prototypes and even MVPs, this has nothing to do with real engineering and will not work beyond things that a junior developer could build.

Here are some hints to become a Product Engineer:

• Broaden Your Perspective

  Start looking beyond tickets and engineering aspects of your work. Learn about user personas, understand the market and the industry, talk to customer-facing teams. Shift from “How to implement all these features?” to “What user problem should we solve?”

• Learn Fundamentals of Product Management

  Familiarize yourself with user research, product discovery, A/B testing, and prioritization frameworks. You don’t need to be a full-blown PM to start, but knowing the fundamentals is necessary to go beyond engineering without reinventing the wheel and making lots of mistakes on the way.

• Communication is Key

  Get comfortable explaining technical issues to non-technical folks, like sales team or marketing leads. Practice active listening to understand user feedback.

• Own Small Features

  Volunteer to lead a small feature end-to-end. Define success metrics, talk to stakeholders, gather feedback, and iterate. This is where you learn by doing.

• Take Over When Product Manager Leaves

  This one might be tough as you will have to make a strong case to explain how come you can replace a full-time role on your own and the organization might not be even aware of a Product Engineer role. But if you have a great credibility, especially as a Tech Lead, this is something you might try.

Wrapping Up

The real 10x developer isn’t the person churning out endless lines of code - it’s the product engineer, the individual who merges strong technical skills with laser-focused product thinking. By owning the entire lifecycle - from understanding user needs and business goals to building and iterating on valuable features - product engineers create outsized impact that goes far beyond a single codebase or sprint metric.

But as soon as you hit twenty or more engineers, even small misunderstandings can quietly balloon into major morale or retention problems. That’s where skip-level 1-on-1s come in. While they’re often overlooked or introduced too late, skip-level meetings can become your secret weapon for sustaining alignment, trust, and engagement as your company scales.

What Are Skip-Level 1-on-1s

A “skip-level 1-on-1” is a periodic conversation between a senior leader - Director, VP, or CTO - and the direct reports of their own direct reports. Essentially, you’re “skipping” one level of management to speak directly with their reports. The value of these chats becomes especially clear during rapid growth, when even your best managers struggle to relay every piece of information accurately and in a timely manner.

When teams expand, it’s not just the engineering headcount that grows. You introduce new managers, shift responsibilities, and roll out new products at a faster pace. Despite everyone’s best intentions, information silos and communication gaps inevitably form. A skip-level 1-on-1 ensures that you hear about these issues - big or small - directly from the people feeling the impact on the ground. This is vital when you want to maintain a pulse on your culture, retain your best people, and keep your roadmap aligned.

The problem is that many organizations adopt skip-level 1-on-1s reactively, only after a major issue forces them to do so. By this moment, you might already suffer from disjointed strategy, or seeing key projects stall. In contrast, leaders who recognize the power of skip-level meetings early and weave them into their growth strategy are far more likely to maintain a healthy culture, empower first-time managers, and catch potential problems before they escalate.

Benefits of Skip-Level Meetings

Here are some key benefits od skip-level-1-on-1s:

Open-Door Policy: Myth vs. Reality

Many leaders often say: “My door is always open” (or “feel free to schedule a call with me any time” in a remote environment). But in practice, many people hesitate to do this uninvited. They might worry about stepping on their manager’s toes or fear being labeled as complainers. A skip-level 1-on-1 reduces this barrier, offering a safe and structured space for employees to talk candidly about challenges, frustrations, and opportunities.

Direct Insight into Team Health

While your first-line managers can (and should) give you status updates, hearing from the team directly brings context and details you might otherwise miss. It’s one thing to see metrics in a dashboard or read a manager’s summary; it’s another to hear an engineer describe how a process is slowing their progress or creating friction.

Career Growth and Retention

Everyone on your team wants to know that leadership cares about their career trajectory. Regular skip-level conversations give you an opportunity to remind them of organizational goals, highlight pathways for growth, and gather feedback on how well those pathways are working. When people feel heard and see tangible follow-through, they’re more likely to stay and remain motivated.

Feedback on Your Management Layer

Skip-levels provide constructive feedback on how your managers are doing. You’ll rarely make decisions based on a single conversation, of course. But over multiple sessions with different team members, you might identify patterns - perhaps one manager consistently excels at building engagement, while another struggles to communicate project goals. This insight is incredibly valuable for mentoring and developing your leaders and managers.

Visibility into Bigger Picture

Senior leaders have broader context, from product strategy to organizational priorities. Skip-level sessions enable Individual Contributors to ask high-level questions about company direction, or to confirm whether their work aligns with bigger goals.

Stepping on Managers’ Toes? Here’s How to Avoid It

It’s natural for frontline managers to worry that skip-level 1-on-1s could undermine their role. The best way to prevent this is by establishing boundaries. Let everyone know that day-to-day decisions remain with the immediate manager. Your role is to listen, help surface issues, and offer support. If a concern arises about a manager’s behavior or leadership style, handle it discreetly. Ideally, by encouraging open communication between both parties.

Introducing Skip-Level 1-on-1s

Introducing skip-level meetings for the first time requires clear communication and a careful approach:

Start with Your Direct Reports
Explain the purpose to your frontline managers: you’re not trying to bypass them or undermine their authority. Emphasize that skip-levels are a feedback loop, not a tool for micromanagement and putting blame on anyone.

Be Transparent with the Team
When inviting someone to a skip-level meeting, clarify why it’s happening and what to expect. Let them know their feedback will remain confidential, except for broad themes you might need to share with managers to fix issues.

Pick a Reasonable Cadence
Quarterly skip-levels often strike a good balance. Too frequent, and you risk overshadowing your managers. Too infrequent, and you may miss urgent problems.

Follow Through
If you learn about systemic issues, work with your managers to address them. Then circle back to the team member who raised the concern so they know their voice was heard.

How To Run Effective Skip-Level 1-on-1s

A good skip-level 1-on-1 is typically 30 minutes to 1 hour. You want structure, but you also want to create space for organic conversation.

Use this template to guide the discussion:

1. Check-In

   • “How are things going for you personally?”

   • “Anything fun or interesting happening outside of work you’d like to share?”

2. Well-Being and Motivation

   • “How do you feel about your current workload and responsibilities?”

   • “On a scale of 1-10, how supported do you feel by your manager and the team?”

3. Career and Growth

   • “What skills are you planning to develop in the next 6-12 months?”

   • “Are you happy with where you are now in your career?”

   • “Is there any training or mentorship you’d find helpful?”

4. Company Strategy and Feedback

   • “Is there anything about our broader strategy you find confusing or concerning?”

   • “If you could change one thing to make our team or product more effective, what would it be?”

5. Open-Ended Questions

   • “Is there anything else you’d like me to know that we haven’t covered?”

   • “Any questions for me, whether about the team, the product, or the company direction?”

Rating morale at the end of the conversation is a valuable practice as it allows you to track the metric over time and compare it with the perception of your managers

Wrapping Up

Whether your organization is adding its first batch of new engineers or you’ve already grown into a larger operation, skip-level 1-on-1s are a powerful way to keep everyone grounded and engaged. They offer a direct line to real feedback, help you catch issues early, and reinforce a culture of trust—especially in times of rapid growth.

If you haven’t tried them yet, this is the perfect time to start. Introduce them carefully, keep the cadence reasonable, and be transparent with both your managers and their teams.

The result? Fewer blind spots, stronger retention, and a healthier engineering culture that stands resilient no matter how fast you’re growing.

It turns out that this is quite a common experience!

Fortunately, it doesn’t have to be that way. There is one simple way how to turn things around. Just spending 5-10 minutes every week/every two weeks on maintaining a Brag Journal can radically change your performance reviews and get you promoted way faster.

And for managers - adopting this practice is also in your best interest. It will make your performance reviews simpler as well as advocating for promotions during performance calibrations. Not to mention that regular journaling and reflection will make the entire team grow so much faster!

Read this article to learn the best practices behind the Brag Journal and adapt it right away to supercharge your own career or the entire teams you manage!

What is a Brag Journal?

The idea behind Brag Journals is simple - every week or two, spend a couple of minutes to reflect and take a note of your work. With a special emphasis on the achievements as this is an opportunity to brag about it. It doesn’t mean that you need to apply some hard-sell tactics and distorting reality, but since the Impostor Syndrome is so common, the opportunity to focus on specific achievements and taking pride in them is a helpful practice.

If that idea sounds to you like debriefing or writing a journal then you are right, this is exactly what it is. Or you might even consider it an equivalent of personal Agile-like retrospective.

And this is exactly why Brag Journals are so useful. It’s not just a list of accomplishments (the “Brag” part). The second part (“Journal”) is equally important, if not even more, as reflecting on your work has a massive educational value. This is where the learning happens and this is the time to think which aspects to improve and how.

Best Practices For Writing the Brag Journal

Even though the idea sounds simple, the proper execution is essential to fully benefit form it. Here are some hints that will help you get started:

Make it a regular and frequent practice

Ideally, schedule it in the calendar to make it non-negotiable, as if it was a meeting! The best interval would be to write it every week, either on Friday or Monday. Spending 10-15 minutes on journaling should be enough.

Doing it every 2 weeks should also be fine, but anything longer than this is a bad idea - you will remember less things which will make it harder to write and you might miss some important details. Also, you would delay any improvements that could be made if you reflected on them earlier.

Measure your achievements

Not everything you do can be easily measured, but if it’s possible, then add as many measurements as possible!

"Improving performance of reads in API v2 by 87% for p50“ sounds way better than “API performance improvements“. If you can link it to a business impact, for example: increasing revenue, decreasing infrastructure cost, helping in acquisition of some customer, even better! This is the best path to getting pro

Don’t the cut the corners during journaling

Writing about achievements is definitely the exciting part of the Brag Journal. Reflecting on your work is the less enjoyable part, but it’s essential for continuous improvements. The common mistake is focusing most of the time on the bragging part and very little on the journaling.

If you want to make the most of this practice, fully commit to every part of it - it’s a great long-term investments and it’s going pay-off big time.

Some things to reflect on during journaling would be:

• What should you do less or more?

• Was there anything that you think you could have done better?

• If you could introduce any improvement on the team or company level, what would it be?

• Is there anything that you are missing at the moment?

• What did you learn?

• Did you enjoy your work? Why/Why not?

• How would you rate your own performance?

• How is your morale?

Include non-quantifiable work in Brag part

Some things are difficult to measure, but it doesn’t mean you should not include them! Contributing to some tricky system design work, unblocking engineers from other teams or starting writing a newsletter on Substack should definitely on the achievements list. This is also the part of your work that your manager might not be even aware of, especially in remote setting. Keeping track of all these initiatives is great for getting on the same page, especially during performance reviews.

Share the Journal with your Manager

And do it often, you can make it even a part of your 1-on-1s! Discussing your Brag Journal works very well for alignment and getting feedback about your work.

Conclude with actionable items

Whenever there are any actionable items (for example, when it’s clear that you should improve communication skills), add them to the to-do list and make sure you act on them.

To make sure that these are not merely items added for the sake of adding them, it’s a good idea to spend some time on reflecting on the progress on them.

Template

Use this template to make the most of your Brag Journaling.

There are a lot of categories there and not all of them will be applicable every time. But it’s simpler to remove not needed parts or keep them blank than add new ones.

The template covers:

• Accomplishments

  • This is the primary Brag part of the Brag Journal

• Notable initiatives you contributed to

  • Not the same as accomplishments, this one is more like status update. But for the notable initiatives.

• Ideas you proposed

  • If there were some interesting initiatives or ideas you proposed, especially if they were well-received, make sure to brag about them!

• How you helped other team members or other teams

  • Unblocking the team(s) is a high-value work that is very often undervalued, so make sure to include it as well.

• Mentorship

  • Both the perspective of being a mentor and mentee.

• Going the extra mile/Extraordinary effort

  • A bit different part than Accomplishments - it’s worth noting all the cases where you went the extra mile. This could be very useful in the context of promotions.

• What you should do more

  • Things than are great and you should do more of them. It could be spending more time on mentoring, sharing knowledge or pair-programming.

• What you should do less

  • Both things that you thought would be good ideas but turned out not to be that good and some clearly undesirable things

• What you learned

  • Emphasize the things you did outside work - pet projects, books, courses…

• What you could have done better

  • Even if things go well, it doesn’t mean it couldn’t be better. If you have a clear idea what you could have done better, note it down and make it an actionable point.

• Things that could be improved on the team level

  • If there is anything on the team level that could be improved, don’t keep it in your head to forget later. Take a note of it and follow up with you manager.

• Things that could be improved on the department/company level

  • Same as for the team-level improvements, but for the wider scope.

• Books/Courses/Pet Projects in progress

  • Related to “What you learned” part - be specific what things are in progress

• Progress on the to-do items from the previous journaling session

  • Review the actionable items from the previous sessions

• To-do items

  • All the actionable items resulting from the current session

It’s also a good idea to rate your own performance and morale. It’s worth distinguishing these two - sometimes you might perform great despite low morale. And if that’s something that continues for at least few weeks, it’s likely that you performance will also suffer soon and this would be an early burn-out stage.

Also, if you think your performance is low, it’s an alarming sign that requires more reflection as well - think what is exactly causing this and what could be some next steps that you could make that would lead to improvement.

Wrapping up

Brag Journals can be a secret sauce to supercharge your career and improve continuously. It’s also an amazing tool to adapt by managers to improve the engineering culture within their teams to help grow the engineers way faster and make it easier to advocate for their promotions during performance calibrations.

If that weren’t the case, you wouldn’t hear so often about people claiming that 1-on-1s are a waste of their time (from both managers and reports).

Let’s learn more about the benefits of 1-on-1s, investigate the common problems with these meetings and what to do instead.

And to make it even simpler to adapt best practices - I will share the template for having awesome 1-on-1-s!

What makes 1-on-1s truly valuable?

The truth is that 1-on-1 meetings if done right, can be truly transformative:

• For reports:

  • getting coaching

  • discussing (career) growth

  • discussing opportunities for promotion

  • getting feedback about your current work

  • bouncing off your ideas

  • understanding what is going on in other teams/departments

  • suggesting improvements regarding your team or the entire organization

  • answers to any questions you might have

  • connecting with your manager on a personal level

• For managers and leaders:

  • building a full picture of what’s going on in the team(s) you manage

  • opportunities for providing mentorship and coaching

  • helping solve ongoing problems

  • getting feedback about your work as a manager

  • connecting with your reports on a personal level

  • maximizing their own output - at the end of the day, the output of the manager is the output of their reports

As you can see, there is nothing about status updates, and for a good reason!

And that’s quite a lot of points to cover. Way more than you could often fit in just 30 minutes! Looks quite different from a meeting that is a “waste of time” during which “there is nothing important” to discuss, right?

Now that we know the benefits, let’s look at some anti-patterns of 1-on-1s.

The common anti-patterns of 1-on-1s

Here are some anti-patterns of 1-on-1s that are very common and that probably everyone in a management/leadership position was guilty of at some point:

Using 1-on-1s for status updates

If 1-on-1s turn into a discussion about status updates, it’s indeed a waste of everyone’s time. This is not even worth discussing in a dedicated meeting as it should be clear from whatever tool you use for project management. Or from everyday casual conversations.

Unless there is something special about some ongoing initiative, you would ideally not discuss this at all during 1-on-1s.

Not having agenda

This is a big issue on both the manager’s and the report’s side. No agenda not only means there is nothing significant to discuss (which makes it questionable if it’s even worth having this meeting), but it’s also impossible to the other party to prepare for this meeting.

Coming unprepared

If there is a clear agenda for the meeting some reasonable time in advance, like one day before, coming unprepared is just disrespectful. Of course, there might be some topics that will require way longer preparation, but at least you should know this before the meeting.

Thinking that 1-on-1s are mostly for managers

It’s a common misconception that 1-on-1s is a meeting that is needed mostly for a manager to get some answers.

This couldn’t be further from the truth! At least if these meetings are not used for the status updates in the first place.

The reality is that the reports are the ones who could benefit from these meetings the most. And the role of the manager is also to coach them about how to make the most of this meeting.

Not having 1-on-1s frequently enough

This is a tricky part as what is “good enough” highly depends on the report. For some, the ideal frequency will be every week, for others maybe every 2 weeks.

There is a catch, though - to make the most of the 1-on-1s, there needs to be a connection and a relationship between a manager and a report. That not only takes time to develop, but it requires also frequent opportunities to build that relationship. That’s why it’s better to have more frequent and shorter 1-on-1s, rather than having a long meeting once per month.

Cancelling meetings often

This is more common when 1-on-1s are considered a waste of time. Still, the takeaway is that when 1-on-1 are done right, they are extremely valuable. If these meetings can be casually canceled often, it’s a clear signal there is something wrong with how they are run.

Discussing actionable things but never making anything about them

The meeting was apparently very fruitful and there are some interesting points to act on. That’s great! Assuming that you are going to follow-through and make sure the right actions are taken.

If there are lots of things discussed during 1-on-1s, but there is never any action taken afterward, then no wonder they are often considered a waste of time.

Applying the same structure and rules to all reports

This might sound counter-intuitive and even contradictory, especially since this article even contains a template. But here is a catch: a template is a template. That’s it. It gives you a solid foundation for a smooth start, but the structure is not set in stone.

It might work perfectly well with most of your reports, but you may need to adjust for others. Maybe for more junior reports coaching should become the focus of the meetings, but for more senior ones, an opportunity to bounce off some of their ideas would be the key part of the meeting?

As a manager or a leader, it’s your key responsibility to understand the other people and work best for them. Don’t assume that you can apply exactly the same thing to everyone and that it’s going to work well.

Template and structure of the meeting

Use this template to make the most of your 1-on-1 meetings.

The template structures the meeting around the following points:

• Check-in

• Wins

• Challenges

• Review of Previous To-do items

• Agenda

• Mentorship/Coaching/Feedback

• To-do items

I’m personally a fan of spending a couple of first minutes on a basic check-in and having a casual conversation. It’s especially beneficial for fully remote companies where you don’t have a chance for random conversations and building relationships with other people that way.

Next, discussing some top wins and challenges since your last meeting works well for building the awareness on your side as a manager and it also gives your reports a chance to brag a bit and raise some concerns about upcoming challenges. Usually, these challenges will be the part of the agenda, but having a bit more structure like this is very helpful in my experience, especially for the future reference.

After that, it would be worth reviewing the outcomes of previous To-do items. It’s essential to make sure that you or your reports take action on what you discuss, so spending a minute or two to align will definitely be beneficial.

Agenda is the key part of the meeting - make sure that you prepare in advance and share this agenda with your reports. And also, make sure your reports also share their points well in advance.

Giving regular and possibly frequent feedback is a great practice - there is nothing worse than waiting with a bunch of comments 5 months after something happened during (bi)yearly performance review when it’s almost impossible to remember all the details. Also, it delays taking any necessary action, so having a fixed place in the meeting structure for this will be very helpful. For less senior reports it’s likely going to be the big part of all meetings.

And the last section is about To-do items - to note any necessary actions to be taken as the result of the meeting.

I would also recommend to rate morale of your reports and how you perceive their performance. It’s totally fine to use you subjective judgement. This can be extremely useful to observe long-term trends and anomalies. For example, a significant drop in morale and/or performance for a few consecutive weeks might suggest someone is on the path to burnout, which would require an immediate attention.

Wrapping up

Even though 1-on-1s are bread and butter for engineering managers and leaders, they are often executed very poorly.

But it doesn’t need to be that way!

Doing 1-on-1s right could be truly transformative for both parties:

• for managers - to maximize the outcomes of their teams.

• for reports - getting feedback about their work, bouncing off ideas, getting coaching, and maximizing chances of promotion

If this is not the case for you, give all these hints I provided a try and see how they work for you. And don’t forget to use the provided template!

Contact

You can follow me on LinkedIn. If there is anything you would like to discuss, just drop me a message!

But in today’s reality, you must also expand your horizon in a few more directions. The pressure of the rapid advancements in AI, the tough market for developers, and at the same time, the end of the Zero Interest Rate Era created a significant challenge for most software engineers and their careers. Being comfortable wearing multiple hats will not be optional - it will become a standard.

At the same time, it’s an amazing opportunity for those who are willing to accept reality, go the extra mile, and learn the critical skills of a modern engineering leader.

Which option do you choose?

To thrive in 2025 and beyond, you must focus on the following aspects:

Tech Leadership

Leadership is a universal skill that will always significantly impact your career, regardless of the circumstances. And fortunately, this is a learnable skill.

And no, you don’t need to have an explicit leadership position to be a leader. Leadership is about what you do and your mindset, not the title. And the sooner you start displaying these traits, the better odds in your favour to become that team leader, engineering manager or staff engineer.

Staying Closer to the Business and the Product

Being a Product Engineer who is not just a “doer” but someone who understands the business and can speak with customers, collaborate smoothly with a Product Manager and a Designer is a superpower that has been growing in popularity in the last months. And for some very good reasons!

It doesn’t mean that you need to become an expert in Product Management, but understanding what you build from the business perspective and knowing the customers of the Product you build makes a massive difference.

Also, understanding practices and frameworks that are the bread and butter for Product Managers can help you big time.

Getting Comfortable with Management

While full-time management is not something everyone will enjoy, Individual Contributors will be expected to take more management responsibilities with more hybrid roles, like a Tech Leader for example, who also manages small teams of 3 to 5 engineers. All this is on top of the Individual Contributor role.

The tricky part is that management is difficult. Even most managers are not great at their job. However, avoiding common mistakes and focusing on the right things will take you far already.

Making the most of the generative AI

While the current generation of LLMs is nowhere close to replacing software engineers, there is no doubt that they are already capable of making skilled engineers even more productive.

And code suggestions via GitHub Copilot in your IDE are probably the least impactful parts of AI. The true productivity boosters are :

• generating prototypes with Windsurf or Cursor

• getting more insights about your codebase

• quickly explore your ideas with ChatGPT/Claude or Perplexity

• generating quick scripts

• getting quickly into new technologies (frameworks, programming languages)

• writing documentation

• making the most of the automation.

If you don’t leverage AI in your everyday work, you might eventually be replaced by someone who does.

Classic Productivity

If getting a productivity boost by 10% or 20% from AI sounds like a great opportunity, then “classic” productivity techniques should be equally well understood.

During challenging days, something so simple as the Pomodoro Technique or Eating a Frog can make a dramatic difference, so having these techniques readily available in your toolset is essential.

Remote work

While working in the office is perfectly fine if that’s your thing, it's essential to be aware of the opportunities, especially as a modern engineering leader, and the massive impact remote work can have on your personal life.

At the same time, remote work is not going anywhere, despite so many RTO mandates. Yes, for Big Tech companies, remote work might no longer be an option, but it’s still popular for smaller companies. If you don’t know how to work efficiently with fully remote/distributed teams, you might find it very challenging while doing the transition so you’d better be prepared for that in advance.

And getting back to the impact on your personal life - would you earn a Big Tech salary in the city with a huge cost of living and commuting every day to the office or earning a bit less (but still a lot) in a place with low cost of living and having a freedom to travel whenever you like to or be able to spend more time with your family and achieve work-life integration instead of settling down for work-life balance?

Communication, writing well, and personal branding

While this could be a surprising point, communication is an essential skill. The stereotype of a software engineer who never talks to anyone couldn’t be further from the truth, especially in 2025! In fact, software engineering has become one of the most collaborative areas.

However, communication is neglected way too often. How many engineers do you know who prioritized getting better at communication over learning a new framework? Probably not that many.

The truth is that improving communication is one of the simpler and at the same time one of the highest ROI investments you can make as a modern engineering leader!

And so is writing well. While AI can help here a lot, it won’t work everywhere - especially when you want to communicate something genuine or important, not just a bunch of facts with some “glue” structure.

While we are on writing well - it’s just a step from personal branding that is heavily based on written content. The market for developers has been especially tough since 2023 and while 2025 might be slightly better than the last 2 years, the reality is that we are not getting back to the golden years of 2021 and 2022 with the best market ever for software engineers. The new era means that you can forget about a classic definition of job security. The new “job security” is your personal brand and network, which has a massive impact on how fast you might be able to land a new position.

Wrapping up

The combination of advancements in AI and the end of the Zero Interest Rate Era accelerated changes in the software engineering industry creating significant challenges for many engineers. But at the same time, this is going to be a great time for Modern Engineering Leaders who are ready to wear multiple hats and go beyond what has been usually expected from being “just a developer”.

Contact

You can follow me on LinkedIn. If there is anything you would like to discuss, just drop me a message!