What happens when a leader who sold the vision steps back into the reality of delivering it?
In this episode of On the Subject of Leadership, I speak with Craig Baker—a technology leader who has spent the past eighteen months in growth and sales at Jarvis—about what he discovered when a customer gap forced him out of sales meetings and back into delivery.
This is not a conversation about sales technique or project recovery. It is a conversation about the distance that opens between leaders and the work they authorise, and what it costs—in credibility, in trust, and in the quality of decisions made on behalf of teams and customers alike.
Craig brings a career that has moved across architecture, delivery leadership, practice-building, and growth. His perspective is shaped less by theory than by the friction of having occupied both sides of the promise: the confidence of selling a solution, and the humility of discovering what it actually takes to build one.
Leadership has a structural tendency to drift upwards. As responsibility grows, proximity to consequence often shrinks. Authority begins to rest on dashboards, forecasts, and carefully phrased assurances. The work itself becomes something reported on rather than touched. This is not a moral failing; it is an organisational pattern. But it carries consequences that are rarely examined until something breaks.
Craig Baker's experience offers a useful case study because he chose to close the distance before failure forced the question.
The Drift and the Return
The trajectory is familiar. A capable technologist builds a delivery practice, earns credibility through results, and moves into sales and growth—where the work is more strategic, the conversations more abstract, and the feedback loops longer. Craig describes this transition honestly: it was a deliberate choice to address a gap in his own experience, and a genuine desire to understand how trust is built at the front end of a customer relationship.
What he did not anticipate was how quickly the texture of the work would fade. Not the knowledge—he could still speak to architecture and integration—but the feel of it: the friction of competing stakeholder priorities, the capacity constraints that no resourcing plan fully captures, the gap between what a solution promises on a slide and what it demands in a production environment.
When a customer engagement ran into difficulty, Craig faced a choice that many leaders in his position avoid: manage the problem through delegation, or step back in. He chose the latter.
What he found was instructive. The team did not lack skill or commitment. They lacked capacity, clarity of priority, and—critically—the confidence to push back on competing demands. The problem was not technical. It was environmental.
Henry Mintzberg has long argued that management is a practice, not a science—that it is learned through experience, reflection, and proximity to the work, not through abstraction. Craig's return to the tools is a practical illustration of that claim. His value was not in solving problems the team could not solve, but in creating the conditions under which they could solve them: shielding them from noise, clarifying priority, and absorbing the organisational risk that junior practitioners are rarely empowered to manage.
The Art of Saying No
A recurring theme in our conversation is the discipline of refusal—and the particular difficulty of exercising it as a third-party vendor.
Craig distinguishes between "no" and "not right now," and the distinction is more than semantic. In his account, the capacity to defer a request without killing it is one of the most consequential skills a technology leader can develop. It protects scope. It preserves the integrity of foundations. And it builds, rather than erodes, trust with customers who have been promised outcomes, not features.
The challenge is that refusal carries different weight depending on where you sit. An internal leader who pushes back on scope is exercising professional judgement. A vendor who does the same risks being replaced. Craig is candid about this asymmetry, and about the temptation it creates: to over-promise in the sales cycle, to absorb unreasonable demands in delivery, and to let the customer's emotional attachment to a process go unchallenged because the commercial relationship is at stake.
His phrase—"you never want to call anyone's baby ugly"—captures the diplomatic reality. But the underlying point is more serious. Consultancies that cannot say no in the right way will eventually say yes to commitments they cannot honour. The short-term commercial gain is offset by long-term reputational cost, and by the corrosive effect on delivery teams who are left to reconcile the gap.
Edgar Schein's work on process consultation is relevant here. Schein argued that the most effective advisory relationship is one in which the consultant helps the client understand the problem, rather than simply prescribing a solution. Craig's instinct—to invest in shared understanding of the problem before proposing an answer—reflects this orientation. It is slower, less commercially efficient in the short term, and considerably more sustainable.
Change Management as the Actual Deliverable
One of the more candid admissions in our discussion is Craig's observation that he has seen excellent technology products fail because adoption was not considered, and mediocre ones succeed because it was.
This is not a novel insight, but it is one that the technology sector continues to underweight. The prevailing assumption—that a sufficiently powerful tool will generate its own adoption—persists despite decades of contrary evidence. Craig's experience in utilities and infrastructure, where end users may be field workers operating in conditions nothing like an office, makes the point vividly. A solution designed for the back office and imposed on the front office will fail, regardless of its technical elegance.
The implication for leadership is direct. If the primary determinant of success is not the technology but the organisational readiness to absorb it, then the leader's role is less about selecting the right tool and more about preparing the right environment. This includes identifying champions early, building consensus among stakeholders with competing priorities, and resisting the temptation to treat the testing phase as the first point of user engagement.
Craig's argument—that super-users and champions should be involved from the earliest design stages, not introduced at training—is a practical application of a well-established principle. It is also one that is routinely ignored under schedule pressure.
Skin in the Game
The conversation takes a different register when Craig discusses the growth of Jarvis from a handful of people to over a hundred. He joined as the fourth or fifth employee, and the distinction between that experience and working within a well-capitalised, externally funded operation is one he returns to repeatedly.
Nassim Nicholas Taleb popularised the phrase "skin in the game" to describe the alignment of risk and reward—the principle that those who bear the consequences of decisions make better ones. Craig's account of building a practice with his own time, money, and reputation at stake is an illustration of that principle in action. When the money is yours, you think differently about what you sell, how you staff it, and what you are willing to promise.
This is not a sentimental point. It has structural implications for how consultancies operate. Craig notes that Jarvis invested almost nothing in marketing; growth came through reputation and word of mouth. That model is only viable when the quality of delivery is consistently high enough to generate referral, which in turn requires a culture that prioritises long-term relationships over short-term revenue extraction.
The counterpoint is worth acknowledging. Not every organisation can or should grow organically. External capital enables speed and scale that bootstrapping cannot match. But Craig's argument is not against investment per se; it is against the detachment from consequence that can accompany it. When the money is someone else's, the temptation to overpromise and under-invest in delivery quality is structurally greater.
Building Teams, Not Just Employing Them
A distinction Craig draws—between building a team and merely employing one—deserves more attention than it typically receives.
The conventional narrative of organisational growth is transactional: secure budget, hire talent, assign work. Craig's account suggests something more deliberate. He describes looking for people who wanted to lead—not necessarily the strongest individual contributors, but those who wanted to empower the people around them. He describes giving those people the opportunity to lead before they had the formal credentials to do so, and watching the effect compound across successive cohorts.
This is the "silent legacy" he values: not trophies or public recognition, but the observation that people he mentored are now leading teams using the same behaviours. It is an intergenerational view of leadership that sits uncomfortably with the quarterly cadence of most organisational performance management.
Laurence J. Peter's famous principle—that individuals in a hierarchy tend to rise to their level of incompetence—is the dark mirror of this discussion. Craig and I discuss the damage done when the only path to advancement is through management, and individuals who excel at technical work are promoted into roles they neither want nor suit. The solution, as Craig sees it, is structural: separate the individual contributor and leadership pathways so that both are valued, and neither is treated as a consolation prize for the other.
The Leader as Multiplier
Craig's self-description as an introvert—"the guy in the corner who doesn't want to talk to anyone"—is worth pausing on, because it runs counter to the extraverted, high-visibility model of leadership that dominates popular culture and, too often, promotion decisions.
His conception of the leader's role is essentially multiplicative. One person can only produce a finite amount of work. A leader who enables four or five people to operate at their best produces four or five times that output—not by doing the work, but by removing the obstacles to it. This requires a deliberate willingness to step out of the technical detail, to absorb blame when things go wrong, and to ensure the team receives credit when they go well.
The asymmetry is important. Craig is explicit that the leader should be at the front when the news is bad and at the back when it is good. This is not a novel formulation—it echoes Robert Greenleaf's servant leadership, among other traditions—but it is one that Craig grounds in a specific and practical mechanism: if the team knows you will absorb the downside risk, they are more willing to experiment, to innovate, and to fail fast rather than fail slowly and expensively.
A More Honest Conversation
If Craig Baker's experience illuminates anything, it is that the distance between selling a solution and delivering one is not merely logistical. It is epistemological. What you know about a problem changes depending on where you stand in relation to it. Leaders who remain at altitude—relying on dashboards, status reports, and the confidence of their own presentations—are not lying, but they are working with a systematically incomplete picture.
Closing that distance is uncomfortable. It reveals friction that abstractions conceal. But it also restores a form of credibility that no slide deck can manufacture: the credibility of having been close enough to the work to know what it actually demands.
If you are responsible for leading delivery, building customer relationships, or growing an organisation where your own reputation is on the line, this is a conversation worth hearing in full.
Please follow On the Subject of Leadership on your preferred platform and never miss an episode.
Good night, and good luck.
