Why This Competency Matters

When interviewers ask 'tell me about a time you had to adapt to shifting priorities' or 'walk me through a major change you had to navigate', they are running a specific probe. The probe is: when the ground moved, did you stay productive, and did you act with agency inside the change?

This is not a probe about flexibility in the abstract. It is a probe about three concrete signals:

[ Agency ]              Did you shape the outcome of the change, or absorb it passively?
[ Professional maturity ] Did you talk about the change in calibrated terms, or in bitter ones?
[ Continued delivery ]  Did your work and your team's work survive the change?

The interviewer's underlying question is forward-looking. Their team will face change in the next year (priorities will shift, leadership will reshuffle, requirements will move). They are trying to predict whether you will be a stabilising influence or a destabilising one when that happens.

Two failure modes dominate weak answers. The first is the victim frame: the candidate describes the change as something that was done to them, with the change agent (a manager, a leadership team, a customer) cast as the antagonist. The signal to the interviewer is that this candidate will be a destabilising voice on their team when the next change hits. The second failure mode is the fake-enthusiasm frame: the candidate claims the change was 'actually a great opportunity' and describes only upside, with no acknowledgement that change has costs. This signals that the candidate either lacks calibration or is performing for the interview, both of which are concerns.

The strong answer threads between these two failure modes. It acknowledges the cost of the change clearly, but the foreground is what the candidate did inside the change to influence the outcome and to keep the work moving.

The Five Change Types You Will Hear About

Most adaptability questions probe one of five change types. The same answer pattern works for all five, but the language and the specific moves differ.

[ Priority shift ]        Project A is paused, project B becomes urgent
[ Org reshuffle ]         Team boundaries, reporting lines, or scope change
[ Technical pivot ]       The chosen approach is wrong; the team must switch
[ Requirement change ]    Customer or product changes scope significantly mid-project
[ Leadership change ]     New manager, new VP, new direction

Priority shift. A project you were leading or contributing to is paused, descoped, or deprioritised, and a new project takes its place. The grading question is whether you can let go of the work you had invested in without bitterness, and re-engage with the new priority with the same level of ownership.

Org reshuffle. Your team's boundaries change. You report to a different person; your team merges with another; your scope shifts. The grading question is whether you can re-establish your effectiveness in the new structure, or whether you spend several weeks complaining about the old structure.

Technical pivot. The technical approach the team committed to turns out to be wrong, and the team has to switch direction mid-project. The grading question is whether you can metabolise the sunk cost and contribute to the new direction, or whether you defend the old direction past the point of usefulness.

Requirement change. A customer or product team changes the scope mid-project. The grading question is similar to the technical pivot, but the change agent is external rather than internal, which makes the temptation to externalise the frustration stronger.

Leadership change. A new manager, director, or VP arrives, often with a different style or different priorities. The grading question is whether you can engage with the new leader on their terms, or whether you signal disengagement (waiting them out, going through the motions).

The questions you will hear most often are about priority shifts, requirement changes, and leadership changes. Reorganisation and technical pivot questions are common at senior and staff levels.

Adapting versus Capitulating

The single most useful distinction in this competency is between adapting and capitulating.

Capitulating sounds like: 'they made the call, so I just did what they asked'. It is passive. The candidate is a recipient of the change, not a shaper of it. Capitulation reads to interviewers as a candidate who will not protect the work, the team, or the reasoning when change hits. They will simply absorb whatever is decided, which is not what the team needs.

Adapting sounds like: 'they made the call, and given the new direction I influenced what we kept, what we let go, and how the transition happened'. It is active. The candidate accepts the decision but acts with agency inside it. Adaptation reads to interviewers as a candidate who will protect the durable parts of the work while moving with the change.

The distinction matters because the strong answer is not 'I went along with the change'. It is 'I went along with the change, and within the change I influenced these specific things'. The 'within the change' clause is what the rubric reads as agency.

Concrete examples of agency inside change:

[ Salvage ]      'I made the case for keeping the scoping work we had done, even though the project pivoted'
[ Continuity ]   'I made sure the new team inherited the documentation so the context was not lost'
[ Sequencing ]   'I influenced the order of the new priorities so the time-sensitive piece was first'
[ Honest framing ] 'I asked the new leader what success looked like in their first 30 days'
[ Boundary ]     'I named the parts of the change I needed clarity on before I could fully commit'

None of these moves overrides the change. All of them shape it from inside.

What Great Looks Like (Rubric)

Strong adaptability answers tend to score on five named signals.

1. The change is real and consequential.

A real reorganisation, a real priority shift, a real requirement change with measurable scope. Stories where the 'change' was a small adjustment that did not require real adaptation fail this signal. The interviewer needs to grade the size of what the candidate had to absorb.

2. The cost of the change is acknowledged.

Good candidates name the cost without dwelling on it: the work that was set aside, the team energy that had to redirect, the timeline that slipped. Stories that pretend the change was costless read as fake-enthusiasm or as missing calibration.

3. Agency is visible inside the change.

The foreground of the answer is what the candidate did within the change to shape it: salvaging useful work, ensuring continuity, sequencing priorities, asking the right questions of the new leader. Stories where the candidate was a passive recipient of the change fail this signal.

4. The language is calibrated, not bitter.

No characterisation of the change agent as the antagonist. No 'leadership did not understand', 'they could have decided differently', 'the requirements team kept changing their mind'. Calibrated language describes the change as a fact and the candidate's response as the foreground.

5. The change produced durable learning.

The candidate names a specific way they now approach change differently because of this experience, with evidence the change has held. Adaptability is a learnable skill, and the rubric rewards candidates who have learned it deliberately.

Common Questions & Model Answers

The six prompts below cover roughly 90% of how this competency is probed. Each model answer is a two-minute STAR answer that scores on the rubric above.

Prompt 1: 'Tell me about a time you had to adapt to shifting priorities.'

Model answer (strong, priority shift on a search-relevance project)

'In Q2 2023 I was the senior engineer leading a search-relevance project for our internal knowledge-base product. We were eight weeks into a twelve-week project and had built about 60% of the new ranking pipeline. In week eight, our VP told us that a competitor had announced a generative-search feature that our largest enterprise customers were now asking about. The new direction was that we needed to ship a generative-answer feature in eight weeks, which meant the ranking work had to be paused.

The cost of the change was real. The ranking work had cost about 30 engineer-weeks of investment across a four-person team, and most of that work would not transfer directly to a generative-answer system. The team morale dropped noticeably the day the change was announced; people had been emotionally invested in the ranking project.

What I did inside the change. First, I asked the VP for a 30-minute conversation about what specifically would carry the new project. Their answer was useful: the generative-answer feature would still need a strong retrieval layer, and the work we had done on document chunking and on relevance signals could feed into retrieval directly. About 40% of the ranking work would carry over, even though the user-facing surface was completely different. I made sure the team heard this directly from the VP rather than from me, which softened the emotional cost of the change.

Second, I worked with my tech lead to identify which of the ranking work was worth completing as a standalone piece. We agreed on two pieces of work that would land cleanly as a v1 ranking improvement, even without the rest of the project shipping. We carved out one engineer-week to land those two pieces; the rest of the team rolled onto the new project. The two pieces shipped a week after the pivot and produced a measurable 8% improvement in click-through-rate on internal searches, which meant the ranking work was not entirely sunk cost.

Third, I named what I needed from leadership for the new project to succeed. I asked for a clear customer-facing success metric (the VP picked answer-quality satisfaction at 70% or above), a clear definition of done for the eight-week sprint, and a single decision-maker for ambiguous scope questions during the sprint. All three were granted.

The eight-week generative-answer sprint shipped on time. We hit 73% on the satisfaction metric in the first month, with the retrieval layer (built on the salvaged ranking work) cited in postmortems as one of the reasons we were able to ship in eight weeks instead of twelve.

What I learned and what I do differently now. I now ask, at the start of any major project, what would still be valuable if the project pivoted at week eight. The exercise sounds pessimistic but it has produced two useful effects: it surfaces which subcomponents of a project are intrinsically valuable versus only valuable in context, and it makes priority-shift conversations easier when they happen. I have done this on three subsequent projects, and on one of them the exercise directly fed into a salvage conversation when the project did pivot.'

What lands: a real priority shift with quantified investment lost (30 engineer-weeks), the cost named without dwelling, agency visible in three specific moves (asking the VP what carried over, salvaging a v1 ranking ship, naming what the candidate needed from leadership), calibrated language that does not characterise the VP as the antagonist, and a durable practice with evidence (the pre-mortem question on three subsequent projects).

Prompt 2: 'Walk me through a major change you had to navigate.'

Model answer (strong, organisational reshuffle)

'In Q4 2023 my company merged two engineering organisations that had been separate. I was a senior engineer on the smaller of the two teams, working on the customer-onboarding service. The reshuffle moved my team into the larger organisation, gave us a new VP, a new director, and a new sister team that owned an overlapping piece of the onboarding flow. The change was announced on a Tuesday and took effect the following Monday.

The cost of the change. My team had built a particular working culture around small, frequent ships and lightweight code review. The sister team operated with a more formal review cadence and a longer release cycle. The cultural mismatch was real; one of my teammates told me in our 1-1 the week of the change that they were considering leaving over the merge.

What I did inside the change. First, I requested 30-minute conversations with the new director and with the lead of the sister team in the first ten days. The conversations were structured: I asked each of them what success looked like for our combined team in the first 90 days, what they were worried about in the merge, and what I could do as a senior IC to help the merge go well. The director's answer was useful: their main worry was that the cultural mismatch would slow shipping, and they wanted a senior IC on each team to be a bridge.

Second, I volunteered to be the bridge from my team. The role was not formal, but it was concrete: I attended the sister team's release meetings, I shared our team's ship cadence with their lead, and I identified two specific places where our processes could converge without either team giving up the parts they cared about. We adopted the sister team's release-notes format (which was better than ours) and they adopted our daily-async-update practice (which was lighter than theirs).

Third, I addressed the cultural mismatch with my own team directly. The teammate who was considering leaving had a specific concern (the formal review cadence would slow their ramp on a feature they cared about). I made the case to the new director for keeping a smaller, faster review cadence on a specific class of changes (low-risk, high-frequency), which the director approved. The teammate did not leave, and the smaller-review-cadence carve-out has held.

Six months in, the merged organisation was shipping at roughly the same cadence both teams had had pre-merge, with the better release-notes format and the carve-out for low-risk reviews. Two engineers from the sister team subsequently asked to rotate onto our work area, which we took as a signal that the merge had landed reasonably.

What I learned and what I do differently. I now treat any organisational change as a chance to ask the new leadership directly what they are worried about and what I can do to help. The conversation is not about asking for things; it is about offering to be useful. I have used this approach in two subsequent reorganisations, and in both the conversations produced concrete asks that I could deliver on, which built credibility quickly with new leadership.'

What lands: a real reorganisation with cultural costs named (teammate considering leaving), agency visible in three specific moves (structured conversations with new leadership, the bridge role, the carve-out for low-risk reviews), calibrated language with no characterisation of the new leadership as the antagonist, and a durable practice with evidence on subsequent reorganisations.

Prompt 3: 'Describe a time when requirements changed significantly mid-project.'

Model answer (strong, requirement change driven by customer)

'In Q1 2024 I was leading a feature project for a B2B integration: we were building a webhook-delivery system for one of our largest customers, with about $400K in annual revenue tied to the contract. We were six weeks into a ten-week project. In week six, the customer told us they needed the webhook system to support a different authentication mechanism than the one we had built (they needed mutual TLS instead of the bearer-token approach we had implemented). The change was driven by a security requirement from their compliance team, not by a change in their preference.

The cost of the change. We had built about 40% of the bearer-token auth path, and most of that code would need to be replaced. The mutual-TLS work was estimated at three engineer-weeks against a four-week remaining budget. The math meant we either slipped by two weeks or cut other scope.

What I did inside the change. First, I scoped the mutual-TLS work in detail with my tech lead before responding to the customer. I wanted to understand exactly what we were committing to before agreeing to the change. The detailed scoping took two days but produced a clean estimate (three engineer-weeks plus a week of integration testing) and a list of three sub-pieces that could be parallelised across the team.

Second, I went back to the customer with a specific proposal. The proposal was: mutual TLS would slip the original ten-week deadline by two weeks, or we could cut the dashboard feature we had agreed to build in weeks nine and ten and ship the mutual-TLS auth on the original deadline, with the dashboard following four weeks later. The customer chose the second option (they cared more about the mutual-TLS auth than the dashboard for the launch).

Third, I ran the trade-off conversation with my own team. The dashboard work had been mostly designed but not yet started. The team had been emotionally invested in the dashboard as the visible part of the project. I made the case for the trade-off (the mutual-TLS path was the contractual requirement; the dashboard was the nice-to-have) and committed to making sure the deferred dashboard work would still ship in the four weeks after the launch. The team accepted the trade-off and the dashboard did ship on the deferred timeline.

The mutual-TLS launch shipped on the original deadline. The customer renewed at the end of the year at a 10% increase ($40K) on the contract value, with the integration cited as a reason for the increase.

What I learned and what I do differently. I now do a 30-minute scoping pass on any mid-project requirement change before I respond, even if the response feels obvious. The pass produces a defensible estimate and a list of trade-offs, both of which make the conversation with the change agent (the customer in this case) much higher signal. I have done this on five subsequent requirement changes; in three of them the detailed scoping revealed a smaller scope than my first impression had suggested, which produced better trade-off conversations.'

What lands: a real requirement change with measurable contractual stakes ($400K customer), the cost named cleanly (40% of work to replace), agency visible in three specific moves (detailed scoping before responding, trade-off proposal to the customer, deliberate trade-off conversation with the team), calibrated language with the customer not characterised as the antagonist, and a durable practice with evidence on five subsequent changes.

Prompt 4: 'Tell me about working through a reorganisation.'

Model answer (strong, reorganisation that changed reporting line and scope)

'In Q3 2022 my team was reorganised. I had been a senior IC on a six-person team that owned the analytics-pipeline service, reporting to a director I had worked with for two years. The reorganisation split our team across two new groups: the analytics team I had been on was absorbed into a larger data-platform team, and three of us (including me) were moved to a new product-platform team. My new manager was someone I had not worked with before. The reorganisation was announced two weeks before it took effect.

The cost of the change. The analytics-pipeline service was a three-year accumulation of context that the new data-platform team would inherit. I knew that context would degrade quickly if it was not transferred deliberately. The two engineers who stayed with the analytics work were both relatively junior; they would lose the senior context that had been on the team. My own move to the product-platform team meant I was leaving a domain I had deep context in for one I would have to ramp up on.

What I did inside the change. First, I spent the two-week window before the reorganisation took effect on context transfer. I worked with the two engineers who would inherit the analytics work to write a 12-page operational runbook covering the parts of the system that were most likely to surprise a new owner: the silent-failure modes, the scaling thresholds, the customer-facing SLAs. I also did three pair-debugging sessions on real ongoing tickets, so the inheriting engineers had walked through the runbook against actual code at least once before the handoff.

Second, I requested a 45-minute meeting with my new manager in the first week of the reorganisation. I went in with a structured agenda: my background, what I had been working on, what I knew about product-platform work, where I was strongest and where I would need ramp time, and what I needed from them in the first month. The meeting was useful in both directions; my new manager later told me it was one of the things that made my onboarding to the new team go faster.

Third, I named the relationships I wanted to preserve from the old team. The two engineers who inherited the analytics work were juniors I had been mentoring; the reorganisation could have ended that mentoring abruptly. I asked my new manager whether I could keep a 30-minute weekly mentoring slot with each of them through the rest of the year. The new manager agreed. The two engineers both grew in their roles over the next nine months, and one of them was promoted to senior eight months later.

What I learned and what I do differently. I now treat any reorganisation announcement as a context-transfer cliff. The window between announcement and effective date is the cleanest moment to write down the context that would otherwise be lost. I have used this on two subsequent reorganisations, both with documented runbooks and explicit handoff sessions. In one of them the handoff prevented a customer-visible incident that the new owners told me would have been a real surprise without the runbook.'

What lands: a real reorganisation with the costs named clearly (context loss, junior engineers losing senior support, the candidate's own ramp), agency visible in three specific moves (operational runbook, structured first meeting with new manager, deliberate continuation of mentoring), calibrated language with no characterisation of leadership or the reorganisation as bad, and a durable practice with evidence on two subsequent reorganisations.

Prompt 5: 'Walk me through a time you had to abandon work you had invested in.'

Model answer (strong, technical pivot)

'In Q2 2023 I was a senior engineer on a team building a recommendation service for our internal product catalog. We had spent about ten weeks on a custom-built collaborative-filtering pipeline. In week ten, after we had run the first end-to-end evaluation, the pipeline was producing recommendations that were measurably worse than a much simpler baseline (about 12% lower on the offline evaluation metric we had agreed to). The diagnosis was that our training data did not have enough density for the collaborative-filtering approach to work; the customer base was not yet large enough.

The cost of abandoning the work. Ten weeks of engineering time across three engineers, plus the design work that had gone into the architecture. The temptation to keep going (we are 75% done, surely we can fix the data density problem) was real and I felt it.

What I did inside the change. First, I framed the decision honestly with my tech lead. We had two options: continue with the collaborative-filtering approach and try to fix the data-density problem (estimated four to six more weeks, with no guarantee of success), or pivot to a simpler content-based approach (estimated three weeks, with high confidence based on the baseline numbers). I argued for the pivot, which was the harder argument internally because of the sunk-cost feeling on the team.

Second, I worked with the team on a sunk-cost framing that was honest. The collaborative-filtering work was not entirely wasted; the evaluation infrastructure we had built was reusable, the data-pipeline work was reusable, and the team had learned a lot about the dataset. About 30% of the ten weeks of work would carry over directly. I made sure this was named clearly so the team did not feel like the work had been entirely lost.

Third, I owned the conversation with our product partner. The product partner had been expecting the collaborative-filtering ship at week twelve. I went to them with the diagnosis (the offline evaluation numbers), the trade-off (pivot now and ship at week thirteen, or push through and possibly slip further with no guarantee of better numbers), and a recommendation (pivot). The product partner accepted the recommendation. We pivoted at week eleven and shipped the content-based recommender at week fourteen, with offline evaluation numbers that beat the original baseline by 18%.

What I learned and what I do differently. I now build a kill-criterion into any speculative project at the start: a specific evaluation result at a specific milestone that would cause us to pivot. The kill-criterion sounds pessimistic but it changes the team conversation when the evaluation comes in. Instead of fighting about whether to pivot, the team has agreed in advance what the pivot trigger is, which makes the actual pivot conversation cleaner. I have used this on four subsequent speculative projects; one of them hit the kill-criterion and we pivoted at week six instead of week ten.'

What lands: a real abandonment with the cost named (ten weeks of engineering time), the temptation to push through acknowledged honestly, agency visible in three specific moves (honest framing with tech lead, sunk-cost reframing for the team, conversation with the product partner), and a durable practice with evidence (kill-criterion on four subsequent projects, one of which actually pivoted earlier).

Prompt 6: 'Tell me about adapting to a new manager or leadership team.'

Model answer (strong, new manager with different style)

'In Q1 2024 I got a new manager. I had been a senior engineer on the same team for about two years under my previous manager, who had a hands-off style and gave me a lot of autonomy. The new manager had come from a different organisation and had a more structured style: weekly 1-1s with a written agenda, monthly written status updates, and a quarterly planning rhythm with explicit OKRs. The change was not announced as a problem; it was just a different way of working.

The cost of the change. The structured style felt like more overhead than I was used to, especially the written status updates. My first instinct was that the new style would slow me down, and I had a private worry that the new manager did not trust senior ICs to operate autonomously.

What I did inside the change. First, I checked the assumption. In our second 1-1, I asked the new manager directly what the structured style was for. Their answer was useful: the written status updates were not about trust; they were about giving the new manager a way to advocate for the team and for individual ICs to leadership above them. The OKRs were about making sure we had a defensible answer to mid-quarter scope-cut conversations. Once I understood the purpose, the overhead made sense.

Second, I engaged with the new style on the new manager's terms. I wrote my first monthly status update in the format they had asked for, even though it was not the format I would have chosen. After two months I had a clearer view of what the format did well and where it had friction; I asked whether I could propose a small adjustment (replacing one of the sections with a different section), which the new manager accepted.

Third, I named what I valued from the previous working style and asked whether it could carry over. I had had a 1-1 cadence with my previous manager that was every other week rather than weekly, with the off-week used for deep technical discussion rather than status. The new manager did not want to give up the weekly cadence, but they agreed to a structure where the second 1-1 of every month would be a deeper technical discussion rather than a status check. This carve-out has held.

Six months in, the working relationship was strong. The new manager later told me that the second 1-1 of every month was one of the more useful 1-1s in their week, and they had adopted the format with two other senior ICs. The structured style I had initially worried about turned out to be a net positive, because of the advocacy upward and because the OKRs did get used in two scope-cut conversations during the year.

What I learned and what I do differently. I now treat any new manager as a chance to check my assumptions about why they work the way they do, before I form a view of whether the style is right or wrong. The check usually surfaces a purpose I had not seen, and the purpose is usually defensible. I have used this approach with two subsequent leadership changes, and in both the conversation surfaced things I would have miscalibrated otherwise.'

What lands: a real leadership-style change with the candidate's initial concern named honestly (private worry about trust), agency visible in three moves (checking the assumption, engaging on the new manager's terms, naming what to carry over from the old style), calibrated language with no characterisation of either manager as the antagonist, and a durable practice with evidence on two subsequent leadership changes.

Pitfalls Specific to This Competency

Four traps that show up most often in adaptability stories:

1. The victim frame. Stories where the change is described as something done to the candidate, with the change agent (a manager, a leadership team, a customer) cast as the antagonist. The signal to the interviewer is that this candidate will be a destabilising voice on their team when the next change hits. Even when the change was poorly handled or the change agent did make mistakes, the foreground of the answer should be what the candidate did inside the change to shape the outcome. The change agent is named as a fact, not characterised.

2. The fake-enthusiasm frame. Stories that claim the change was 'actually a great opportunity' and describe only upside, with no acknowledgement that change has costs. This signals that the candidate either lacks calibration or is performing for the interview. Strong answers acknowledge the cost of the change clearly (work set aside, team energy redirected, timeline slipped) before describing the agency the candidate exercised.

3. Capitulation dressed up as adaptation. 'They made the call, so I just did what they asked' is not adaptation; it is capitulation. Adaptation requires agency inside the change: salvaging useful work, ensuring continuity, sequencing priorities, or naming what the candidate needed from the new direction to make it work. Stories without visible agency inside the change fail the rubric, even if the candidate accepted the change cleanly.

4. No durable learning. A change story without a specific way the candidate now approaches change differently scores about a B regardless of how cleanly the rest is told. Adaptability is a learnable skill, and the rubric rewards candidates who have learned it deliberately. Generic morals ('I learned to be more flexible') do not score; concrete practices with evidence do ('I now do a pre-mortem on every project asking what would carry over if it pivoted', applied to N subsequent projects).

Practice Prompts & Exercises

For each prompt below, draft a 250 to 350 word STAR answer using the four-part structure (situation plus cost plus agency inside the change plus durable learning). For every story, mark explicitly: the size of the change, the cost you acknowledge, the specific moves you made inside the change, and the durable practice with at least one piece of evidence the practice has held.

1. Tell me about a time you had to adapt to shifting priorities.
2. Walk me through a major change you had to navigate.
3. Describe a time when requirements changed significantly mid-project.
4. Tell me about working through a reorganisation.
5. Walk me through a time you had to abandon work you had invested in.
6. Tell me about adapting to a new manager or leadership team.
7. Describe a time you stayed productive when your team was in flux.

For every story, also do the language audit. Read the answer out loud and ask: do I name the change agent as the antagonist anywhere? do I dwell on the cost of the change instead of moving to my agency inside it? do I describe the change as costless? Strong answers describe the change as a fact, name the cost briefly, and put the foreground on agency.

Bridge / Cross-References

This lesson is the second in the Resilience & Adaptability category and pairs naturally with handling-failure. The most useful Foundations companions:

• star-method provides the structural backbone for the four-part adaptability pattern (situation plus cost plus agency plus learning).
• crafting-compelling-stories is essential because adaptability stories often live or die on the framing of the change agent; the difference between calibrated and victim framing is often a sentence-level edit.
• quantifying-impact powers the cost-of-the-change signal in the model answers above.
• interviewing-for-senior-roles is essential for level calibration; adaptability stories at staff and above usually involve cross-team or organisation-level changes, not individual project pivots.

Within this category, this lesson sets up working-under-pressure (the next lesson, which covers a different stress vector: not changing requirements but high-stakes execution) and dealing-with-ambiguity (the staff-level competency where the candidate has to act before the change has even been named). Together these four lessons cover the spectrum of how interviewers probe for stability and judgement under non-ideal conditions. The growth-mindset signal that runs through all four (durable behavioural change with evidence) is one of the strongest cross-rubric signals in the loop.