A room for Developer experience teams

Developer Experience Studio

Find the small obstacles that slow developers down and choose what to fix first.

Why this might help

Every developer team has tiny speed bumps that nobody talks about out loud. Things like hunting for a config file, waiting on an unclear ticket, or re-reading the same Slack thread three times. A friction log is a simple habit: you write down those small annoyances as they happen, then your team looks at the list together and decides what to fix first. It's not about big process overhauls. It's about noticing the little stuff before it quietly eats everyone's day.

Does this feel familiar?

  • A developer asks the same setup question in Slack every time someone new joins the project.
  • People skip the ticket description and just ping the author directly because the brief never has enough context.
  • A pull request sits for two days because nobody knew whose turn it was to review it.
  • Someone spends twenty minutes finding the right API docs link that should have been one click away.

Try this together

  1. Start a shared doc this week and ask everyone to drop in one friction point they hit — no judgment, no fixing yet, just collecting.
  2. Read the list together in your next team meeting and group similar items so you can see patterns instead of a pile of complaints.
  3. Pick the one friction point that comes up most often or blocks the most people, and treat that as your only focus for now.
  4. Try a small fix — like adding a links section to your ticket template — and check in after two weeks to see if that specific pain actually went away.
  5. Keep the log open and running so new friction gets captured as your codebase and team grow, not just during a one-time audit.

Developer Friction Log

  1. Create a simple shared document or spreadsheet with three columns: What happened, How long it took, and How often it probably happens.
  2. Ask each person on your team to log friction points for one full week — even tiny ones, like 'couldn't find the staging URL again'.
  3. At the end of the week, read every entry together and mark duplicates so you can see which problems are shared, not just personal.
  4. Score each item by two things: how many people it affects and how often it happens, then sort by that score to find your top candidates.
  5. Choose one item from the top of the list, assign a clear owner, set a two-week window to try a fix, and then log whether the friction actually went away.

Questions worth talking about

What's one thing you had to figure out this week that you feel like you've had to figure out before?

If a new developer joined tomorrow, where would they get stuck in their first three days?

Which part of our current workflow do you quietly work around instead of actually using?

A few common questions

How is a friction log different from a regular bug tracker?

A bug tracker captures broken code. A friction log captures broken experiences — things that technically work but slow people down anyway. That includes unclear docs, missing context in tickets, and awkward handoffs. Those things rarely make it into a bug tracker because nobody thinks to file them.

What if the team feels like complaining is pointless because nothing ever gets fixed?

That feeling is real and it's worth naming out loud. Start by fixing one small thing quickly — something you can actually change in a day or two. A fast win shows people the log isn't just a venting space. It builds enough trust to keep the habit going.

Can Tindlo help with any of this?

Tindlo lets your team attach files, links, and a brief directly to work items on a shared time-based view. If missing context or scattered links show up in your friction log, keeping that information inside the work item itself — where everyone can see it — is one practical way to reduce that specific kind of friction.

Keep the story close to the schedule

A date makes more sense when you can also see the reason, the owner, and the work around it. Tindlo brings those pieces together when a calendar alone isn't enough.

See how Tindlo works →

Where would you like to go next?

Engineering Leadership ExchangeEngineering leadersProduct Operations CircleProduct operations teamsProject Managers' WorkshopProject managers