Salary reviews, status tools, and observability 💡

Monday Ideas — Edition #131

🔧 Budibase — build internal tools in minutes

I am a big fan of using low code solutions to create internal tools.

I have written many times about it: it’s a way to get things done fast, while reducing the surface of the code you have to maintain.

For this reason this week I am happy to promote Budibase, which saves engineers 100s of hours building apps and automating internal workflows.

It's open source, connects to any data source, offers free SSO, and is loved by over 200,000 engineers worldwide.

Back to this week’s ideas! 👇

---

1) 🎽 How to prep for salary reviews

Earlier this year we wrote a full piece about how to do good salary reviews. Many companies do this at the end of the year — if that’s the case for you, you should prepare in three steps:

Market Research 🔍

Regularly benchmark salaries to ensure competitiveness and retain talent. This can be done by HR or engineering managers, depending on your company structure.

Useful salary data sources: Payscale, Levels.fyi, Glassdoor

Performance Data Collection 📊

While opinions vary on linking performance to salary, it's crucial to have a clear, fair process. I usually rely on the following principles:

• 💰 Consistent raises — if the budget allows, I aim to give a minimum yearly raise to every team member, including those with average performance. Of course, there may be years when this minimum raise cannot be met.

• 🌟 Rewarding excellence — for exceptional performers, I aim to provide a bonus in addition to the minimum yearly raise.

• 🗣️ Seeking feedback — I never rely solely on my judgment. I seek feedback from colleagues who have worked closely with the person being reviewed.

Related to performance, we wrote a full piece about performance reviews last year.

Budget Planning 🧮

Once you have a clear understanding of fair compensation for your team, it’s time to plan your budget. Develop a comprehensive plan for raises, considering:

• 💰 Financial constraints — understand the overall budget limitations and financial health of the company.

• 🔄 Competition — keep up with industry salary trends to ensure competitiveness.

• 💡 Strategic priorities — consider the company’s strategic goals and how salary adjustments can support these objectives.

• 🌟 Employee retention — factor in the importance of retaining top talent and how competitive salaries can aid in this effort.

Include specific reasons for planned raises to aid in negotiations with upper management. You can find the full piece below!

How to Deal with Salary Reviews 💰

---

2) ⚖️ Single tool vs multiple tools

For status updates, async exchanges through docs and tools are the main alternative to meetings. While tools seem easier, most are specific to certain use cases and users.

So what do you do? Two options work:

1. 📁 Single tool — stick with one source of truth, prioritizing consistency over UX, e.g., use Notion for everything.

2. 🗃️ Multiple tools — use specialized solutions for different use cases, prioritizing UX over consistency, e.g., use Notion for OKRs and Jira for tasks.

The choice depends on team skills, product, and scale.

Using a Single Tool 📁

A single tool reduces inconsistencies and delays. The main challenge is ensuring good UX for all stakeholders.

Teams can enhance the tool with custom visualizations, automated workflows, and chatOps. Examples: Visor + Jira, Glide + Google Sheets, Softr + Airtable.

Select a tool with a strong ecosystem and granular data handling capabilities.

Using Multiple Tools 🗃️

Using different tools for different jobs can work but poses two main risks: 1) confusion about what goes into each tool, and 2) inconsistency — info may need replication, risking stale data.

To counter these:

1. Clarify boundaries — make the scope and responsibilities of each tool clear. For instance, use Notion for OKRs, Linear for tasks, and store projects on both with links.

2. Clarify ownership — ensure it's clear who owns and updates each tool. For example, PMs own Notion project pages, while TLs or EMs maintain Linear ones.

3. Use automation — set good boundaries to minimize overlap and use tools like Zapier for automation if needed.

How to Choose 🎲

Both styles can work. Consider how much action happens on the tools by stakeholders. If deep UX differences exist, you may need to split tools.

This should be a collaborative choice:

• Talk with people — ask stakeholders what they need.

• Use tools in meetings — prototype tool usage in meetings to ensure clarity and comfort with the workflow.

• Take baby steps — test one use case at a time and proceed when everyone is satisfied.

You can find our full piece about keeping stakeholders aligned below! 👇

How to Keep Stakeholders Aligned 📣

---

3) 📊 Observability vs Monitoring

Earlier this year I interviewed Charity Majors, and at the beginning of our chat we discussed the difference between Observability and other related concepts like monitoring, APM, and more.

Charity, who also wrote a book about it — explained how observability is a property of complex systems, just like scalability, or performance. Even more so, it is about socio-technical systems, not just your tech:

• If you add more metrics, you are improving observability.

• If you educate your team on how to ask questions about the system, you are improving observability as well.

Observability helps understand the intersection of software and users, and is like the business intelligence of tooling: it’s the single source of truth where you can break down, zoom in, and zoom out information about your systems, together with information about your customers.

More specifically, good observability is based on three pillars:

• 📊 Metrics — offer insight into the health and performance of a system

• 🔀 Traces — map the journey of a request or action as it moves through all the nodes of a system.

• ✏️ Logs — provide detailed records of events and activities within the system.

Together, these form the backbone of any observable system, enabling teams to monitor and address system issues in real-time.

You can find the full interview here:

Observability & Testing in Production — with Charity Majors 🎙️

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.

2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.

I wish you a great week! ☀️

Luca