1. Unclear expectations

When people are not sure what good work looks like or what matters most this week, they work hard on the wrong things and feel they are never getting it right. What helps: a short weekly priorities note and regular one-to-ones where expectations are checked, not assumed.

2. Too much work, for too long

Busy periods are normal. A permanently unmanageable workload is not. What helps: ask about workload on a regular rhythm, and when it is too high, take something off the plate or agree what will wait.

3. Feeling unheard

People raise concerns, nothing visibly changes, and they stop raising them. Silence is not agreement. What helps: tell people what you heard and what you will do, even when the answer is "not now, and here is why".

4. Little sense of growth

People want to learn and see where they could go next. What helps: ask what they would like to learn, agree one small step and revisit it.

5. Weak manager relationship

Many people say they leave managers more than companies. Managers who are hard to reach, rarely give feedback or react badly to bad news make staying difficult. What helps: regular, predictable one-to-ones and feedback that is specific and timely.

6. Not feeling recognised

Good work that is never noticed erodes motivation. What helps: specific, timely thanks that says what the person did and why it mattered.

7. Poor fit between the job and the person

Sometimes the role changed, or was described differently when the person joined. What helps: check in during the first months and revisit the role as it changes.

8. Change that is not explained

Reorganisations and new tools are easier to accept when people know why they are happening. What helps: explain the reason, the impact on each person's work and the support available.

Spotting problems early

Short, regular check-ins surface these themes while there is still time to act. The same few questions each round, kept brief, let you see whether something is slipping in a team. Do not wait for an exit interview to find out.

What to do with what you hear

1. Look for the theme that appears most.
2. Choose one action and give it an owner and a date.
3. Tell the team.
4. Check again to see whether it helped.

A note from us

Ethos One is an AI-powered pulse, insight and accountability ecosystem for companies of 50 to 500 people. Its 10-second check-ins turn into actions with an owner and a date, and later check-ins show whether those actions worked. It is a live product, in open beta since 23 June 2026, with 14 days free access at ethosone.ai/company/register.

Written by the Ethos One team.

What an engagement survey measures

Different surveys use different wording, but most cover the same handful of themes:

• Clarity: do people know what is expected of them and why it matters?
• Workload: is the amount of work realistic?
• Manager support: can people get help and useful feedback?
• Growth: do people see a path to learn and progress?
• Recognition: is good work noticed?
• Belonging and communication: do people feel included and informed?

A good survey measures a small number of these at a time rather than everything at once.

Types of engagement survey

1. Annual survey. A long survey once a year. It gives a broad baseline but the results can be months old by the time anyone acts.
2. Pulse survey. Three to five questions, sent every week, fortnight or month. It spots change early.
3. Lifecycle survey. Short surveys at moments that matter: after onboarding, after a promotion, at exit.
4. Topic survey. One-off, focused on a single decision such as a new working pattern.

Most teams that do this well combine an occasional broader survey with regular short ones.

How often to run one

Choose a rhythm you can actually keep. Weekly suits fast-moving teams, monthly suits most others, and a longer survey once or twice a year gives context. The rule that matters more than frequency: do not ask more often than you can act on the answers. If people answer and nothing changes, they stop answering honestly.

A simple way to run the first one

1. Pick one topic you are ready to act on.
2. Write three to five questions: mostly rating scales, one open comment.
3. Tell people why you are asking and when they will hear back.
4. Share the main themes in the time you promised, even when the news is mixed.
5. Choose one or two actions, give each an owner and a date.
6. Ask the same questions again next round and report whether things moved.

Common mistakes

• Asking too many questions, so completion drops.
• Changing the wording every round, so nothing can be compared.
• Collecting answers without sharing results.
• Producing charts but no owners or dates.
• Treating a low score as a verdict on a manager instead of a prompt to ask what would help.

Reading the results

Look for themes in the open comments before looking at the scores. Comments usually explain the numbers. Compare a team with its own earlier rounds rather than with other teams, because context differs. Small groups need care: report themes rather than individual comments so people stay comfortable being candid.

Where tools help

You can start with a spreadsheet and a form. When you want the answers, the actions and the follow-up check-ins in one place, a tool helps. Ethos One is an AI-powered pulse, insight and accountability ecosystem for companies of 50 to 500 people. Its 10-second check-ins turn into actions with an owner and a date, and later check-ins show whether those actions worked. It is a live product, in open beta since 23 June 2026, with 14 days free access at ethosone.ai/company/register.

Written by the Ethos One team.

If you've ever run a site through Google's PageSpeed tool, you've seen a wall of acronyms: LCP, CLS, INP, FCP, TTFB. They look technical, but each one answers a simple question about how your page feels to a real person.

This guide explains them in plain English, then shows how to pull the same numbers automatically using Google's free PageSpeed Insights API.

The three metrics Google cares most about

Google calls these the Core Web Vitals. They're the ones that count as a ranking signal, so they're worth understanding first.

1. LCP (Largest Contentful Paint): "How fast does the main content show up?" It measures how long it takes for the biggest visible thing on the page (usually a hero image or a big headline) to appear. If it takes forever, visitors stare at a blank or half-loaded screen.

2. INP (Interaction to Next Paint): "How fast does the page react when I click?" You tap a button, open a menu, or type in a field. INP measures the delay before the page visibly responds. A laggy page feels broken even if it loaded quickly.

3. CLS (Cumulative Layout Shift): "Does the page jump around?" You're about to tap a link, then an ad loads above it and everything shifts down, and you tap the wrong thing. CLS scores how much stuff moves unexpectedly while the page loads.

What counts as "good" Metric Good Needs work Poor LCP under 2.5 s 2.5 to 4 s over 4 s INP under 200 ms 200 to 500 ms over 500 ms CLS under 0.1 0.1 to 0.25 over 0.25

A quick note: you'll still see FID (First Input Delay) in older articles and tools. INP replaced it as the official responsiveness metric, so focus on INP.

Two helper metrics worth knowing

These aren't "core," but they help you find why the main ones are slow.

FCP (First Contentful Paint): when the very first piece of content appears. If this is slow, the problem starts early. TTFB (Time to First Byte): how long your server takes to start responding. A slow TTFB (often bad hosting or no caching) drags every other metric down with it. Two kinds of data: lab vs. field

This trips up a lot of people. PageSpeed gives you two different types of results:

Lab data: a simulated test run on Google's servers, right now. Great for debugging because it's repeatable. Field data: real measurements from actual Chrome users who visited your site over the past 28 days. This is what Google uses for ranking.

If your lab score looks great but your field data is poor, real visitors (maybe on slower phones or networks) are having a worse time than the test suggests. Always look at both.

How to check them with the PageSpeed Insights API

You can use the web tool at pagespeed.web.dev, but if you want to check many pages, track changes over time, or build your own dashboard, the free API is the way to go.

Step 1: Get an API key. Create a project in Google Cloud Console, enable the "PageSpeed Insights API," and generate a key. It's free for normal usage.

Step 2: Make a request. The API is just a web address you call with the page you want tested:

https://www.googleapis.com/pagespeedonline/v5/runPagespeed ?url=https://example.com &strategy=mobile &category=performance &key=YOUR_API_KEY

strategy can be mobile or desktop. Mobile is the one that matters most, since Google indexes the mobile version of your site first.

Step 3: Read the results. The response is a big chunk of data. The useful parts are:

Lab metrics: lighthouseResult.audits (look for largest-contentful-paint, cumulative-layout-shift, first-contentful-paint, and so on) Field metrics: loadingExperience.metrics (real-user data, including LCP, CLS, and INP)

Here's a simple example in JavaScript:

javascript async function checkVitals(pageUrl, apiKey) { const endpoint = "https://www.googleapis.com/pagespeedonline/v5/runPagespeed" + ?url=\({encodeURIComponent(pageUrl)}&strategy=mobile&key=\){apiKey};

const res = await fetch(endpoint); const data = await res.json();

const audits = data.lighthouseResult.audits;

return { lcp: audits["largest-contentful-paint"].displayValue, cls: audits["cumulative-layout-shift"].displayValue, fcp: audits["first-contentful-paint"].displayValue, score: data.lighthouseResult.categories.performance.score * 100, }; }

checkVitals("https://example.com", "YOUR_API_KEY").then(console.log); One important rule: keep your API key off the browser

If you build a tool that calls this API, never put your key directly in front-end code. Anyone can open their browser's developer tools, copy it, and use up your quota.

The safe approach is to have a small server-side piece sit in the middle: your page calls your server, your server calls Google using the secret key, and then passes the results back. In Next.js, this is what an API route does. The key stays on the server, and visitors never see it.

What I learned building a tool around this

I built a Core Web Vitals checker with Next.js on top of this API. A few lessons that apply to anyone attempting something similar:

Show the numbers in context. A raw "LCP: 3.1 s" means nothing to most people. Pairing each number with a good / needs work / poor label makes the report instantly readable. Be ready for slow responses. The API runs a real test, so it can take 10 to 30 seconds. Show a loading state so people know it's working. Handle missing field data. Small or new sites often don't have enough real-user data, so the field section comes back empty. Don't treat that as an error. Just fall back to lab data and say so. Keep it light. A performance tool that's itself slow defeats the purpose, so I kept the interface free of heavy UI libraries. Quick fixes for the most common problems If this is bad... Try this first LCP Compress and properly size your hero image, use modern formats like WebP, and add caching INP Cut down heavy JavaScript and remove unused plugins or scripts CLS Set width and height on images and ad slots so the browser reserves space TTFB Better hosting, server-side caching, or a CDN The takeaway

Core Web Vitals sound intimidating, but they boil down to three questions: Is it fast to appear? Is it quick to respond? Does it stay still? Check them with the PageSpeed Insights API, look at both lab and field data, and fix the biggest problem first. Small wins on mobile add up quickly.

Muhammad Habban writes about technical SEO, web development, and building practical tools. Connect on LinkedIn.