Develop a Software Development team: Beyond Speed to Strategic Velocity

Fri, 16 Jan 2026 00:00:00 +0000

In an era of rapid technological flux, where AI increasingly permeates daily life and significantly impacts the business sector, organizational leaders frequently confront a complex set of challenges: “How do we drive the organization forward while sustaining profitability and growth?”, “How do we keep pace with competitors?”, “How do we maintain our competitive edge?”, “How do we foster employee engagement, ownership, and skills, while simultaneously accelerating workflow?”, and crucially, “What is our AI strategy?” to expedite the software development process. From the adage of yesteryear, “big fish eat small fish,” to the subsequent era of “fast fish eat slow fish,” today, speed alone suffices not. One must possess the direction to guide the organization forward with both speed and orientation—Velocity. For if an organization moves too slowly, or rapidly but in an erroneous direction, it invariably leads to business failure.

1. Speed vs. Velocity

Itamar Friedman, CEO of Qodo, offered a simple yet potent definition: “The difference between Velocity and Speed is that Velocity has a vector.”

Focusing solely on speed makes the team appear perpetually busy, releasing new features frequently (High throughput), but these activities may not generate positive impact. Research titled “Speed vs Direction: Why Moving Fast Isn’t Always Progress,” Innovation and Strategy, Ibid. indicates that nearly 70% of Digital Transformation projects fail because execution precedes strategy. For large enterprises or organizations in highly regulated industries, rushing to code as fast as possible without quality assurance can lead to costly errors (AI-driven software development: Navigating the shift from speed to velocity, LinearB Blog).
Velocity is progress with purpose. For large organizations, Context Management and precision are essential. Thus, evolving from “vibe coding” to clear structural planning is paramount.

2. Defining via Vision and Strategy

To achieve Velocity, the team must first determine “Where do we want to go?” before asking, “We need to adopt AI; how do we execute this quickly?”

Vision is the long-term future image, akin to a North Star guiding the way. Strategy is the plan detailing how teams, systems, and processes will collaborate to realize that vision. Leaders must communicate this vision clearly to inspire and provide definite direction to the team (10 Strategic Thinking Techniques Used by Global Leaders, KCT Academy Thailand).

A tool aiding direction definition is the North Star Metric Framework (NSM), a key indicator reflecting the core value customers derive from the product. Having an NSM ensures all organizational parties (Product, Engineering, Marketing) work in alignment, focusing on the same outcome rather than working in silos (The Ultimate Guide to the North Star Product Framework, GeeksforGeeks).

3. Focus on Outcome over Output

Building software is not about increasing throughput; it is about injecting value into that throughput (Deliver Value).

In a case study on teams focusing on impact from the article Stop Obsessing Over Development Velocity, Focus on This Instead, Itamar Gilad notes that in experiments, teams that reduced throughput but spent time on Product Discovery and focused on the Success ratio generated better business results than teams focusing on throughput by fourfold.

Jeff Patton, a product expert, stated, “Your job isn’t to build more software. It’s to build less software (Minimize output) so that you can maximize outcome and impact.”

4. Techniques for Fast and Accurate Decision Making

Having direction does not imply slowing down. Research titled Making Fast Strategic Decisions in High-Velocity Environments by Kathleen M. Eisenhardt states that executive teams in the microcomputer industry found that teams deciding quickly and efficiently exhibit these behaviors:

Use Real-time data: They track operational metrics like daily bookings and cash flow closely, rather than relying solely on future forecasts.
Consider Simultaneous Alternatives: This helps visualize strengths and weaknesses comparatively and immediately reduces risk.
Employ a conflict management process: Fast teams use “Consensus with Qualification”—attempting to find consensus, but if unattainable, the leader makes a decisive call based on team input to avoid aimless waiting.

5. Balancing Tactical and Strategic Mindsets

Developers and team leaders must adapt their mindset appropriately.

Tactical: Focusing on the immediate task and solving immediate problems to complete the work.
Strategic: Focusing on the big picture, the future, and problem prevention.

Excessive tactical work leads to a “Crisis management loop” and burnout, while excessive strategic work can cause “Analysis Paralysis.” Good leaders must maintain this balance (The Strategic Vs. Tactical Mindset, DEV Community).

It is evident that software team development in the digital age is not a coding speed race, but a competition of who can “learn and adjust direction” towards creating customer value faster. Speed is merely an accelerator, but Velocity (Speed+Direction) is the true strategic asset. Successful organizations are those that cease running after currents, choosing instead to define clear goals and sprint towards them with agility.

Fail Fast: When 'Failure' is the Cheapest Cost of Building a Great Product

Fri, 05 Dec 2025 00:00:00 +0000

In the world of work, especially when building a Product, we are often taught to fear mistakes. We are conditioned to believe that perfection is the finish line and failure is something to avoid at all costs.

But in the reality of today’s fast-paced world… “Perfection that comes too late might be worth zero.”

Today, I want to invite everyone to adjust their perspective on Fail Fast through a thought process called Design Thinking, to see why daring to fail early is actually the safest strategy in business.

The True Meaning of “Fail Fast”

Many people misunderstand Fail Fast as doing sloppy work or just letting things break. In reality, Fail Fast is a philosophy of “Risk Management.”

It is asking the question:

“How can we learn the most important things using the least amount of resources (money, time, labor)?”

Because failing while we are still drafting on paper is always less painful than failing on the day we have invested in building a factory or writing millions of lines of code.

Design Thinking: The Tool That Helps Us “Fail” Valuably

When we pair Fail Fast with Design Thinking, we find that every step is designed for us to “test fail” in a safe space to harvest “lessons” for improvement.

1. Empathize & Define: Ditching Wrong Assumptions

The scariest starting point isn’t making an ugly Product, but making a Product that “no one wants.” The first step of Fail Fast starts with walking in to talk to real users.

What happens: We might find that the problem we thought was huge is actually trivial for the customer.
The Lesson: Admitting that “what we thought all along was wrong” is the first failure of immense value because it stops us from walking the wrong path from the very first step.

2. Ideate: The Space for Trial and Error

In the brainstorming phase, we often fall into the “love at first sight” trap with the first idea we think of.

Concept: Allow the team to propose ideas that are “crazy” or “impossible” as much as possible.
Filtering: Throwing away 99 ideas to leave 1 right idea isn’t waste, but a necessary filtering process to ensure we are betting on what is most worthwhile.

3. Prototype: Build to Learn, Not Build to Sell

This is the heart of Fail Fast. Instead of secretly building the Product to 100% completion, we should create something called an MVP (Minimum Viable Product) or just a simple model.

It might be just a drawing on paper (Sketch).
Or a cardboard model that is tangible.
Goal: Make it as fast as possible to spark questions and criticism.

4. Test: The Moment of Truth

Taking the Prototype to test isn’t to receive compliments like “So pretty,” but to observe real behavior.

If the user is confused, can’t use it, or ignores the feature we are proud of… that is good news.
The good news is that we have “failed” at the lowest cost, and the data from that failure is the compass that tells us where to adjust to make the real Product most complete.

Turn “Fear” into “Learning”

Ultimately, building a Product with the Fail Fast and Design Thinking mindset doesn’t teach us to be losers, but teaches us to be “Learners.”

In a constantly changing world, successful people aren’t those who “never fail,” but those who “get up the fastest” and take lessons from those scrapes to create things that truly answer people’s needs.

Hope this article is useful for you to dare to try and fail systematically to get a product that meets customer needs. Ask yourself…

Have you tried to “fail” to learn something new today?

Management on TECHFOR by Suriya Sonphu