Dialogic Leadership in Digital Transformation
Nour
Founder, Coachful
Dialogic leadership in digital transformation helps leaders examine how people understand a proposed change, including the experience that a rollout plan may overlook. The conversation becomes useful when it changes a question, an option or an action, with decision authority and technical requirements still clear.
This guide focuses on a recurring tension: creating dependable common processes while responding to legitimate local differences. Its complete fictional example follows a work-order redesign from a contested proposal through a limited demonstration, a mixed result and an inaccurate update that needs correction. It does not assume that conversation produces consensus or authorizes deployment.
Distinguish dialogue, conversational actions and polarity thinking
In his 1999 article Dialogic Leadership, William Isaacs describes listening, respecting, suspending certainty and voicing one’s considered view. Suspending involves making thinking available for examination, rather than suppressing it or presenting it as unquestionable. Respect includes investigating how another person’s position makes sense to them.
Isaacs credits David Kantor for four conversational actions: move, follow, oppose and bystand. These concern what people do in an exchange. A person can initiate an idea, support its development, challenge it or offer perspective on the conversation. They are not fixed personality categories, and a missing challenge can matter as much as a missing proposal.
Barry Johnson’s Polarity Management distinguishes ongoing, interdependent demands from matters that can be resolved by a choice or an answer. If both needs remain necessary over time, selecting one permanently may create another problem. This is a separate lens from Isaacs’ practices and Kantor’s actions.
Use the lenses deliberately. They do not combine into a standardized digital-transformation method or establish that every disagreement has two equally acceptable sides.
Ask what the organization’s current story makes hard to see
Bushe and Marshak’s 2009 paper, Revisioning Organization Development: Diagnostic and Dialogic Premises and Patterns of Practice, examines different assumptions about organizational change. Its dialogic account emphasizes meaning-making, the conversations people have and the emergence of new ways to understand organizing.
The authors contrast this with diagnostic approaches organized around analysis and planned change. They also retain shared humanistic values and warn against combining practices without understanding their premises. Their argument is more specific than saying that any well-facilitated meeting constitutes Dialogic Organization Development.
For a digital-transformation conversation, ask what a familiar explanation permits or excludes. Calling a branch “resistant” may obscure a workflow the proposed software cannot accommodate. That possibility needs inquiry. It does not mean that test results, access requirements or evidence about a failed function become matters of opinion.
Identify the continuing tension and the finite decision
A common data structure can help staff interpret records across branches. Local discretion can help staff respond to conditions that differ between sites. If every branch invents incompatible meanings, a shared system may become hard to use. If a common process excludes legitimate work, staff may have to improvise outside it.
Those are continuing design needs. Whether to authorize a particular demonstration on a particular date is a finite decision. Whether an application can restore a saved field is a testable question. Keep these categories separate.
| Question | Kind of work required |
|---|---|
| How will branches share reliable records while handling different site arrangements? | Recurring coordination and local-response tension |
| May six staff try a non-operational prototype? | A decision by the authorized owner, within stated conditions |
| Does recovery preserve the saved site route? | A defined technical check and response to its result |
| May staff bypass a required access control? | A requirement for the appropriate owner to apply, not a preference to trade away |
The polarity management guide develops the recurring-demand distinction. The example here uses an original worksheet, rather than reproducing an owner’s formal mapping instrument.
Worked example: a common workflow that omitted a local route
All people, records and events below are fictional. A repair business wants to replace several branch spreadsheets with a common work-order system. Maren leads the transformation. Suri owns operations and can authorize the proposed demonstration. Jan leads product development and owns the prototype and recovery checks; Peta reviews the relevant security and data conditions. Noor represents branch users. Ravi is the internal meeting facilitator.
Coach Eli works privately with Maren in two 50-minute sessions on 3 and 24 November 2026. Eli is not the project approver, technical assessor or steering-meeting facilitator. Project decisions remain in the company’s controlled decision record. The coaching agreement includes no sponsor report or between-session message support.
The initial proposal requires an on-site person’s mobile number in every work order. Maren’s draft briefing describes branch reluctance as an adoption problem. It recommends more training and one mandatory format.
Prepare a question that remains open to correction
In the first session, Eli asks Maren what would count as evidence against that explanation. Maren realizes she has examples of incomplete fields, but has not asked why those particular fields were left incomplete. She changes the briefing question:
Which information must have a common meaning for everyone, and where does the proposed process fail to represent legitimate site arrangements?
Maren sends the revised brief to the six meeting participants on 3 November. They can comment in the company’s project document or email her privately before the meeting. They may also contribute orally during it. Restricted customer details are excluded; Noor brings an invented example of the relevant site arrangement.
Ravi agrees to facilitate the 4 November discussion from 10:00 to 11:00, Europe/London. Suri confirms that the meeting may authorize preparation and checks, but operational use needs a separate explicit decision. The invitation does not present attendance or silence as approval.
Hear the contribution behind the apparent opposition
Noor explains that some industrial sites require visitors to report to reception. A particular named person and personal mobile number are not the permitted access route. Staff have been leaving the field blank because the prototype has no truthful answer for that arrangement.
Ravi initially paraphrases this as a training need: “We need to explain why contact details matter.” Noor corrects him. She agrees that staff need a reliable route to enter the site. Her point is that the form requires the wrong kind of route.
Ravi withdraws his summary and asks Noor to describe the sequence. Maren acknowledges that her adoption explanation missed this distinction. The written record changes from “branches need to complete the contact field” to “the shared workflow needs an approved reception-route option.”
Jan now proposes a common set of status, owner and site-identifier fields, with a controlled choice of site-access route. Peta says the actual data fields and use of business contact details still need review. Noor supports examining that option, without accepting that it will work.
This is the practical value of the dialogue: a previously excluded condition changes the proposed design. It is not proof that resistance has vanished or that everyone now wants the same system.
Make the conversational actions visible without assigning identities
The following original contributions show the different actions within this exchange:
- Move, Jan: “Keep the common status fields, and offer a separate approved route for reception-based sites.”
- Follow, Noor: “I can supply a fictional reception example so we can inspect that choice.”
- Oppose, Peta: “We cannot assume every proposed free-text contact detail belongs in the record.”
- Bystand, Maren: “We have been treating incomplete fields as reluctance before checking whether a truthful answer exists.”
Later, Jan challenges the request for unrestricted branch customization. Noor proposes a common name for the reception option. Their contributions change with the question. Ravi does not appoint a permanent opposer or require someone to challenge merely to complete a pattern.
Complete the coordination-and-local-response worksheet
The group records the continuing needs separately from the immediate permission. These entries are its own design reasoning, not evidence that a particular balance has been validated.
| Field | Common coordination | Local responsiveness |
|---|---|---|
| Useful contribution | Status, owner and site identifier mean the same thing across branches. | Staff can represent a permitted reception route without inventing a personal contact. |
| Risk when pursued alone | A required field can force an untrue placeholder for legitimate work. | Uncontrolled labels can make records unintelligible elsewhere. |
| Chosen design question | Which fields need shared definitions? | Which approved alternatives cover actual site arrangements? |
| Evidence to inspect | Whether users select the intended status and owner. | Whether reception-based examples can be represented accurately. |
| Warning to retain | Staff supplying a placeholder to pass validation. | Branch-specific text whose meaning other staff cannot establish. |
The worksheet does not authorize collecting additional personal data. Peta’s review remains a separate condition. It also does not settle every local difference: the group deliberately limits the first demonstration to routine and reception-based examples.
Use a sixty-minute meeting to reach a bounded result
Ravi’s completed meeting follows this original working agenda. The time blocks fit the agreed hour; a longer organizational inquiry would need a separate arrangement.
- Eight minutes: confirm the question and authority. Suri distinguishes preparation from operational authorization. Ravi explains comment routes and the record’s audience.
- Twelve minutes: inspect the branch evidence. Noor describes the reception route. Ravi’s inaccurate training summary is corrected before the group moves on.
- Fifteen minutes: examine the continuing needs. The group completes the worksheet and identifies shared definitions and permitted alternatives.
- Fifteen minutes: specify an inspectable option. Jan proposes the prototype, Peta names the conditions for its synthetic records, and participants discuss scope.
- Ten minutes: record the decision and open conditions. Suri authorizes preparation only. Maren reads the recorded result back, and Noor corrects an omitted reception-route requirement.
The blocks total 60 minutes. The actual decision is useful precisely because it says what has not been authorized. No production data, operational scheduling or customer communications may be changed through this demonstration.
The GOV.UK guidance on service governance connects evidence, decision authority and explicit boundaries. Its setting is government service delivery. The fictional private business has its own authority structure; the guidance does not certify that structure or replace its controls.
Show the complete decision brief and the approval sequence
Maren saves the following decision brief in the company’s project record after the meeting. Participants receive the record link through their company email. This is the project’s actual approval route; Coachful is not used as the engineering authorization system.
Question: May six staff try a non-operational prototype using synthetic work orders to examine the shared fields and reception-route option?
Scope: Six individual 20-minute sessions, two invented work orders per participant. The prototype cannot write to the live system. Existing spreadsheets remain authoritative for real work.
Conditions before the demonstration: Peta must confirm the proposed synthetic fields and permitted examples. Jan must confirm the prototype is isolated from operational records. Suri must then explicitly authorize the sessions.
Evidence: Record the common-field choices and handling of reception-based examples separately. Retain incorrect entries and participant explanations.
Not authorized: Operational use, migration, extra personal contact details or wider rollout.
Next decision: Suri will consider the demonstration evidence and technical readiness separately. A favorable user response alone cannot authorize operational use.
On 6 November, Peta confirms the bounded synthetic-data arrangement in that record. Jan confirms the isolation check. Suri then gives written authorization for the six demonstration sessions on 9 November. These are fictional observed approvals, rather than instructions pretending that somebody else has already agreed.
Six staff volunteer, two from each of three branches. Noor is one participant. Jan facilitates all six 20-minute sessions. That represents 120 participant minutes and 120 facilitator minutes for the demonstration sessions themselves. It is not the whole project cost: preparation, the steering meeting, analysis and later engineering work are separate work.
Let mixed observations change the next question
The six participants each attempt two synthetic work orders, producing 12 submitted records. The records comprise seven routine examples and five reception-based examples.
| Observation | Actual result | Interpretation limit |
|---|---|---|
| Common status, owner and site identifier all correct | 10 of 12 records | The two errors concern the owner field; completion alone was not correctness. |
| Reception route represented correctly | 4 of 5 reception-based records | One participant still entered a placeholder personal number. |
| Unique participants | 6 across 3 branches | Two records per person do not constitute 12 independent users. |
The groups overlap. Noor’s reception example is one of the two owner-field errors and contains the placeholder. Cian makes the other owner-field error in a routine example. The group does not add the two success counts together or report them as a single adoption percentage.
Jan’s notes show that the owner label still resembles a contact-person label. He changes the wording and separates the route choice from that field. On 11 November, Noor and Cian each repeat one relevant synthetic example. Both enter the owner correctly; Noor also selects the reception route accurately.
That is a narrow retest by two people who have already encountered the prototype. It does not replace the initial 12-record result or establish performance for all staff, other site types or live conditions.
A separate recovery check on 12 November uses four defined scripts. Three preserve the expected fields; one loses the saved site-route field. The technical owner records the failure. This is a defect to investigate, not an acceptable price for local responsiveness.
NIST’s SSDF Version 1.1 describes high-level secure-development practices that can be integrated into different development life cycles. The current publication list distinguishes that final version from the Version 1.2 draft. Dialogue can improve the questions put to technical owners; it does not establish that a system is secure or ready.
Correct the transformation leader’s own report
Maren’s 12 November email to the steering group says, “The pilot passed; users can now work with a common process.” That compresses the mixed demonstration and the recovery defect into a success claim. It also calls a non-operational demonstration a pilot without explaining the distinction.
Jan challenges the wording on 13 November. Maren checks the record and sends a correction to the same recipients that day:
My previous summary overstated the result. This was a synthetic demonstration, not an operational pilot. The initial common-field result was 10 of 12 records; reception-route selection was 4 of 5 relevant records. Two participants completed a narrow retest after wording changes. Recovery passed three of four scripts, with one failure still open. Operational use has not been approved.
Suri acknowledges the corrected status. Maren asks Jan to present the recovery position at the 19 November review; Jan accepts that review request on 13 November. At the actual review, he reports that the failure remains unresolved. Suri records that operational authorization remains withheld. The team retains the wording changes as design learning but makes no migration commitment.
In the final coaching session on 24 November, Maren sees a familiar assumption returning in her own reporting: a positive narrative was crowding out the conditions. She chooses to preserve separate user-learning and technical-readiness sections in future briefs. Their future use and the eventual recovery repair are unknown when the coaching ends.
Prepare the leader’s inquiry in Coachful
Coachful is our #1 recommendation for preparing and reviewing the individual leadership work around these decisions. An original worksheet can help the client identify assumptions, omitted voices, requests and the evidence they will bring back. It does not replace the organization’s project record or authorize a technical release.
Give the intended client access to the worksheet and explain who can read submitted answers. A copied private resource link alone does not grant access. The form-builder image illustrates structured preparation, rather than a proprietary polarity assessment.
For Maren, the practical task could be to replace the adoption claim with an open question and bring the actual decision record to the next session, subject to company information rules. The goal image illustrates linked activity. An app task marked complete cannot establish that Suri authorized a demonstration or that recovery passed.
Keep coaching-team review notes separate from material intended for a client or sponsor. An unshared journal page is not readable through coach access. Where enabled, Share with coach intentionally exposes that individual page; keep sensitive personal words unshared. Check automatic recap settings and any session-type override before putting restricted project content into a session record.
The case includes two scheduled sessions, with no extra coaching channel. A worksheet does not add an immediate response promise. Use Coachful’s features to support the agreed preparation and follow-through, and retain engineering evidence in the authorized company system.
Troubleshoot the conversation and its record
People keep repeating their positions. Ask for one concrete example and what it changes about the proposal. Noor’s site sequence changed a field requirement. Asking her to state her preference again would not have exposed the missing route.
The decision owner dominates the evidence. State what remains open to change, offer a contribution route outside the live exchange and record a concern in the contributor’s terms. Invite correction of the summary. Do not promise anonymity if the actual audience or example makes the contributor identifiable.
Every issue is called a polarity. Separate the ongoing needs from today’s authorization and the defect that requires correction. A recurring desire to improve service does not make an unresolved access or recovery failure optional.
A useful meeting is reported as transformation success. Inspect what actually changed: a question, a requirement, an approved demonstration or an observed behavior. Preserve the gap between those outputs and operational adoption. Correct an overstatement in the same communication route through which it spread.
Frequently asked questions
Does dialogic leadership require consensus?
No. Inquiry can expose disagreement or an unmet condition. The decision owner still needs to use the organization’s actual authority and record the outcome. Someone supporting a smaller demonstration has not necessarily endorsed the eventual rollout.
Which digital-transformation polarities are useful to examine?
Choose continuing needs that genuinely depend on each other in your setting, such as shared definitions and legitimate local responsiveness. Test that interpretation against actual work. Avoid attaching two attractive words to a finite choice or treating a required control as negotiable.
Are Isaacs, Kantor and Johnson describing the same framework?
No. This guide uses Isaacs’ dialogic practices, Kantor’s conversational actions as credited by Isaacs, and Johnson’s ongoing-interdependence distinction. The worksheet, meeting agenda and fictional example are original applications, not a combined certified method.
How can a coach assess whether the conversation helped?
Compare the question, proposal, response and decision before and after the exchange. Ask what the client did differently and what actual evidence remains. A changed requirement can be useful without establishing that dialogue caused a better business outcome.
Can a coaching platform hold the release approval?
Use the organization’s designated authority and record for release decisions. Coachful can support a leader’s reflection and agreed actions. Access to a worksheet, a positive recap or a completed task is not technical assurance, formal business approval or proof of deployment readiness.
For a separate delivery-method question, see the Agile and Waterfall dialogue guide. This article’s concern is representing legitimate work inside a shared digital process.
