Back to Basics: The Hidden Strength of Resilient Teams
- Agnė Jaraminaitė
- Jan 6
- 11 min read
By Agnė Jaraminaitė, with insights from technology transformation leader Šarūnas Dargelis
Executive Summary
As organizations rush to adopt new technologies, frameworks and methodologies, many forget to examine whether the fundamentals of how they work still hold. Teams often add new layers – new technology advancement like AI, new processes and/or Ways of Working, additional governance, which may be driven for good cause and need or because the market or competitors are doing so. Yet without strong basics, every new layer increases fragility. Returning to fundamentals is not always regression – often it is the foundation of resilience. Resilient teams understand their systems deeply, revisit assumptions regularly and embed a discipline of inspection that prevents silent inefficiencies from growing into crises. Leaders must ensure that the basics are institutionalized, that inspections are routine rather than reactive and that teams view going “back to basics” as a strategic strength rather than a sign of weakness - this allows adjusting to shifting markets and adopting new technologies like AI into strong backbone of resilient teams.
Why “Back to Basics” Matters More Than Ever
In many organizations, new frameworks, tools or processes are adopted not because they solve a specific problem, but because the market is typically inspired by large consulting firms like McKinsey, BCG, Bain&Company or Gartner Magic Quadrants which suggests they should. “Trendy boost up may create extra “noise” in the Engine Room for organizations ,” technology transformation leader Šarūnas Dargelis reflects. “Teams introduce new technologies or Ways of Working simply because competitors are doing it or seen in one of the conference show-case. And in some instances neither show-case has proof (pioneering at best), nor teams and leaders cannot even explain why, which then becomes a trend-driven reaction instead of a purposeful decision based on strong foundation and proactive growth.”
This reactive layering creates an illusion of progress often hindering may operations and delivery capacity. When the foundation beneath these layers is weak – unclear ownership, outdated architecture and product/service foundation, low-quality feedback loops – innovation only may accelerate dysfunction. Returning to the basics forces leaders and teams to examine whether the core of their product or service still works and are relevant to market. It is not about abandoning innovation, but more about ensuring it grows from a stable, comprehensible base.
How “Back to Basics” Coexists With Continuous Improvement
Many executives assume that going back to basics contradicts continuous improvement with growth, but these forces are complementary. Returning to fundamentals is what allows improvement to be sustainable. Dargelis emphasizes that to understand this relationship, leaders must look beyond surface-level practice and revisit foundational principles.
“If your processes aren’t working, if the product foundation is weak, adding more on top won’t help,” he explains. “Poor feed-in results in poor outcome. Back to basics means asking: does the foundation still support what we’re trying to build?”
He uses a simple analogy: adding AI to a product that customers don’t love will not fix the underlying issue. Before improving, teams must review the core – business assumptions, technology stack, organizational alignment. In long-lived products, this means examining fundamentals that may not have been revisited for five or ten years and taken as given/always working that way. Continuous improvement is therefore not a linear ascent – it is a cycle that routinely returns to the starting point to ensure the path forward is still the right one.
What the Shu–Ha–Ri Model Teaches About Maturity
To describe the path from basics to maturity, Dargelis turns to the Japanese learning concept Shu–Ha–Ri, used in martial arts and increasingly referenced in technology delivery. “Shu means Following the rules,” he explains. “You do things as the master teaches. Many teams operate here – they implement and adopt practices because others do, which may come without understanding of why.” Ha means Break the rules: after learning the practice, understanding the theory, exploring variations, and adapting it to organizational needs. Ri is transcended: creating new practices that fit the unique context of the team or organization.
However, he points to a fourth stage that is rarely discussed but deeply relevant to modern organizations: Kokoro, meaning Heart.
“Kokoro means going back to the center,” he says. “Even after you learn Following rules, adapt by Breaking rules and transcend by creating new ones, you must return to the basics to Simplification and Excellence of what your Products/Services are about in its core. You check whether the foundation is still strong both organizational, technology and business market-wise. The other layers can only create value if the basics hold. Otherwise, you build complexity on sand.”
This model reveals a truth many teams miss: mastery is about moving outward and then back inward in cycles. Great teams revisit fundamentals precisely because they understand their importance.
Why Teams Skip Straight to Innovation Without Mastery
Innovation carries prestige – basics may not so evidently. As a result, many organizations skip foundational steps strengthening and improvements while jumping straight into experimentation of new Tech. “Teams don’t want to be laggards,” Dargelis observes. “They see a trend – AI, a new framework, a new tool and they want to try it. And trying is good. But not if it replaces the importance of strong foundation.”
He explains that in Agile, healthy experimentation happens through so called Spikes: small, time-boxed explorations that do not compromise the core Product, Service delivery. A team may explore how AI agents could streamline monitoring or automation, but they do so without abandoning stream-lined processes. Innovation without disciplined mastery may turn around into organization productivity, product/service delivery and team morale downspiral but innovation built on solid basics in place is transformative.
When Markets and Teams Change, Returning to Fundamentals Enables Adaptation
In todays fast-moving markets, teams often confuse effectiveness and efficiency with relevance. Nokia is a familiar example. “They were delivering perfectly,” Dargelis recalls. “They hit every KPI but the market shifted and mobile phones that were top product at the time were replaced by smartphones .” Teams that rely solely on their own performance metrics may miss underlying market signals which may often be silent. This strengthens the need for both strong core with basics and constant reinvention that can and must happen for resilience.
Returning to fundamentals means examining whether the product is still valid and needed, whether its architecture supports future changes and whether teams understand shifts in customer behavior. Sometimes this means strengthening the foundation. Sometimes it may be killing the product entirely.
“Going back to basics may mean reinforcing or scrapping and then moving the team to new Product/Service that is relevant to the market,” Dargelis notes. “Both can be right.”
When Should a Team Run an Organizational or Technical Inspection?
Many organizations delay system inspections until something visibly breaks, even though quieter early warning signs show up much sooner. Delivery may still be on time while quality quietly declines. Velocity may be stable while customer usage drops. Morale may fall even as throughput remains high. “Sometimes everything looks good on paper,” Dargelis says. “KPIs are green, Ways of Working events are ongoing but something is off. That is when you must inspect deeper.”
Triggers for inspection vary: new leadership, rapid scaling, a product pivot, repeated outages or long periods of silence in retrospectives. In many organizations, silence is the most dangerous sign of all. If no one raises issues but quality, morale or customer signals decline, the basics may have eroded.
Healthy teams embed inspections into their rhythm: every two to four weeks in review validating learning and retrospectives for inspection and adaptation of what is requiring fixes, every quarter in broader reviews and periodically in deep architectural assessments. Without these cadences, teams may become busy to produce Product/Service but unaware that they are moving off the market target.
Measuring What Actually Works
Modern team metrics traditionally are velocity (team speed), throughput or cycle time that reveal more how effective a team is but not whether delivering the right things. “It straight back comes to the customers we serve,” Dargelis stresses. “Are we hearing the real end-users and focusing iteration Goals to meet the adjusted Product/Service needs?
He has seen organizations with great processes and rich dashboards, consistent metrics, but feedback loops that were too good to be true versus end results of the contracts for delivery. If surveys capture the same small group of respondents or missing real end-users feedback, it creates the illusion of satisfaction and decline is inevitable. The hardest question for executives is often the simplest: Does metrics match reality?
Where Hybrid Delivery Systems Break Down and How to Inspect Without Blame
Hybrid delivery models – Agile + ITIL + DevOps or elements of Waterfall and Governance continue to grow because modern organizations require flexibility across technology, operations and compliance. But hybrids often collapse when applied blindly. “Teams get stuck in Shu (following the rules),” Dargelis warns.
“They do practice because the book says so. Others even worse jump straight to Ha (breaking the rules) – changing practice without even trying it as is to see what works and what does not. Both paths alone break hybrids. But when done together can help to learn the knowledge and build understanding in practice and transcend into Hybrid suiting Team and Organization for Successful Product/Service and happy Clients”
The key to diagnosing Hybrid model success or failure is to inspect systems, not individual elements. “Never look at single elements alone,” he emphasizes. “Look at how the system is organized.” Hybrids break down when the system combines frameworks without understanding their depth or purpose. They succeed when teams understand why each piece exists and where it applies and clear roles to contribute for Product/Service success.
Uncovering Silent Inefficiencies
Many inefficiencies may be silent productivity and motivation destroyers. Unclear ownership, invisible or not addressed technical debt, or recurring dependency bottlenecks weaken team performance. Dargelis recalls a case where all Product teams blamed an Integration team for delays. “Everyone called them the bottleneck, but when we inspected their backlog, it was three or four sprints beyond capacity. The system was overloading them,” he says.
The fix required structural change: redistributing integration capacity into teams who can work together and without additional handshakes across teams. Silent inefficiencies thrive when teams do not speak openly or systems are not inspected holistically with Action taken. The longer they persist, the more effort it takes to repair.
Knowledge vs. Understanding
Many teams possess partial or theoretical knowledge of Agile, ITIL or DevOps but struggle in practice because of required practical understanding. “Theory without practice creates complexity that doesn’t work. Practice without theory works for a moment but can easily collapses at scale,” Dargelis notes. Certified professionals may know the frameworks deeply but lack real experience and understanding, while practitioners may deliver well but misunderstand why certain practices exist or what can further be enhanced, optimized. Both perspectives are insufficient alone and strong when combined.
“You validate theory with practice and practice with theory,” he emphasizes. “That balance is where maturity lies.”
Organizational and Technical Layers of Inspection
Teams must distinguish between inspecting the way they work together and inspecting how their system actually runs. Organizational inspection covers communication, roles, priorities and cross-team dynamics. Technical inspection evaluates build pipelines, deployments, observability, architecture and stability. Confusing these layers leads to misdiagnosis.
Dargelis shares an example from a multi-vendor aviation project lead back in Montreal, Canada: “Different companies representatives and engineers came into the same room. Each had their own contractual piece. I shared with them a simple thinking rule: we can leave badges outside the door if needed but we have to work as one team now - building working Solution that has to replace ten other systems. Contractual discussions if any scope challenges can happen elsewhere.”
During the project it was just the few occasions requiring contractual discussion along the way but had happened without disrupting team and delivery. Once organizational part is sorted, team can work on technical excellence. The result working as one team was the client’s first successful multi-vendor delivery because the team was able to focus on building the System without single minding its own part only.
The Minimal Fundamentals Every Team Should Master
Before scaling, teams must secure both organizational and technical foundations. On the technical side, this means having reliable Continuous Integration and Continuous Deployment (CI/CD) pipelines, strong test automation, stable architecture, clear ownership and meaningful observability. On the organizational side, it means mastering the basics of teams setup, Ways of working, wether it is Agile, Waterfall or Hybrids (more: Hybrid Methods: What Does “Agile + X” Really Mean for Delivery and Operations?), understanding the purpose behind each practice, and establishing strong feedback loops with validated market learnings.
Failing to strengthen foundations early forces teams to rebuild later - often at far greater cost. “Sometimes you must update, upgrade or redo the foundation partially or in full,” Dargelis says. “It may take months, but it can enable five to ten years of future scalability and save hundreds of hours of manual work e.g. test automation for speed delivery.”
From Resilience to Evolution
Resilient teams do not resist change – they embrace it through strong foundations. “Radically simple foundation sound easy,” Dargelis notes. “But it takes organizational and technical excellence with discipline to simplify and reinvent. Once foundation is strong, adaptability becomes natural.” Automation, stable architecture and clarity of ownership allow teams to pivot without destabilizing the system. Resilience is therefore about the ability to evolve without breaking - like sailing ship on strong winds and high waves.
How Technical Inspection Becomes Continuous Learning and Improvement
In many Waterfall mismanaged environments true inspection may happen only when failure becomes unavoidable or too late to fix e.g. Integration phase when some fundamental Design phase flaws could have been identified and validated with fixes having smaller release. In contrast, modern resilient teams embed inspection into continuous learning cycles ideally two to four weeks time with market validation of working Product/Service increments allowing to pivot for Success even with cyber-physical solutions (hardware+software).
Dargelis notes that leadership often acts effectively and timely when the financial impact is understood.
“Translate issues into currency, quantify impact of risk or customer loss. When leaders understand the cost of not acting, they support change or accept the risk” he says.
Inspection without action erodes trust. Inspection with action creates mutual trust and resilience.
Is Maturity Stability or the Ability to Reset?
Maturity may be often misunderstood as consistency – continuing to do what worked in the past. True maturity is the courage to reset. Dargelis explains: “Not being afraid to revisit everything – that’s maturity. Sometimes it is better to refocus people on a new product than continue investing in a dying one.” He returns to the Nokia example: high performance according to internal metrics was not enough. The market had moved, but the organization had not.
Building a Culture Where Going Back to Basics Is Strength, Not Failure
Sustaining a healthy culture requires good communication – open, honest, constructive and non-judgmental. Teams must feel safe to discuss technical foundations, architectural issues and systemic challenges. Leaders must allocate time for architectural reviews, organizational inspections and exploratory spikes. Ignoring foundational problems pushes talent motivation away; addressing them builds trust and resilience. “It’s okay to go back to the drawing board,” Dargelis concludes. “Some of the best ideas and strongest teams bonds emerge from there.”
Executive Imperatives: Three Questions for Leaders
Have we mastered the basics?
If foundational practices are inconsistent, attempts to improve or innovate before fixing it will magnify dysfunction.
Are we designing deliberately or reacting to trends?
Leaders and teams must define what organizational structures and technology choices apply and why rather than adding new layers and stitching it together reactively.
Is ownership preserved?
Resilient teams reinforce the principle “you build it, you own it.” Fragmented accountability undermines it regardless of technology, framework or ways of working.
About Šarūnas Dargelis
An information technology leader with more than two decades of experience driving large-scale organizational transformations and delivering complex projects and products.
He is recognized for building high-performing teams and navigating diverse delivery models – Traditional (ITIL, PMI, Prince2), Agile (Scrum, Kanban, Spotify, SAFe, LeSS) and Hybrid. His expertise extends to embedding AI in business processes to streamline service delivery and simplify operations.
Šarūnas holds an MSc in Business Informatics and brings deep experience across industries including financial services, insurance, manufacturing, telecommunications, transportation, healthcare and life sciences, aerospace, and defense. He is certified as CSP-SM/PO, PMP, ITIL, CSPO, CSM, MSP, SAFe SPC, RTE, LPM and LeSS.
