Speed Through Competence
March 01, 2025
The other week, I heard an interesting little sound bite:
Speed doesn’t mean quality is bad; speed could mean incredible competence.
It didn’t stop me in my tracks when I heard it (or I’d remember exactly where I heard it from), but I’ve been turning this idea over and over in my head since.
While an incredibly simple idea, its implications are large. For example, if this idea is true, can you ever mention that quality might suffer if you move too fast on a project? Or are you really admitting incompetence?
While I think the answers to the above questions are “yes” and “maybe,” respectively, I wanted to flush out my thoughts on this to see if it resonates with other engineers. In an environment with ever-increasing pressure to ship quickly, understanding your levers and opportunities to increase speed while keeping quality high seems like a good idea.
What is Competence
So, what do we mean when discussing competence as a software engineer?
The Webster’s definition of competence goes like this:
the quality or state of having sufficient knowledge, judgment, skill, or strength (as for a particular duty or in a particular respect)
To me, being a competent engineer is about using skill, knowledge, and judgment to solve problems with code.
It’s important to call out here this requires more than just programming skills. Project planning, judgment and evaluation of tools or techniques, and communication skills are vital to being a competent engineer. We need to utilize all of our breadth and depth of expertise to solve problems critical to our business or communities.
We aren’t paid to write code; we are paid to solve problems. It does require writing code (and lots of it!), but it also requires knowing what code to write, when, and why.
The Project Triangle
Now that we’ve discussed what competence is, let’s go back to discussing the core tension of speed vs. quality regarding that competence.
The tension of speed and quality comes from the Project Triangle. The Project Triangle is a framework or model for thinking through the core constraints of delivering a project.
The triangle moves across three constraints: scope, time, and cost. The idea is that if the scope increases, the other two factors will also increase. i.e., a larger project should cost more and take more time (whether that actually happens is another article!).
Now, let’s say you have a fixed-scope project. Regardless of whether that scope is small or large, there will always be pressures to deliver that scope as fast and with as little cost as possible while still keeping quality high.
Over time, this has developed into a common phrase:
You can have it good, fast, or cheap. Pick two.
What this means is that a project can be delivered in one of three paradigms: 1) fast and high quality but also high cost 2) fast and cheap but low-quality 3) high-quality and cheap but slow
The question now is this: does the introduction of competence or skill as a factor invalidate this principle?
In my view, absolutely not. Here is why.
More competent engineers are more expensive. If you have a project with more skilled engineers, chances are the project is more expensive than if there were less competent engineers.
Of course, there are exceptions and variances when it comes to cost and skill in the industry. Many highly skilled junior engineers can outperform senior engineers any day of the week. But generally speaking, more experienced and more expensive engineers will be more expensive.
The other reason I think these principles hold is that, from the perspective of a single project, everyone will always) want to move faster. So even if you have highly competent engineers who can move at a breakneck pace, from the project perspective, there will always be a desire for them to move _even faster.
This means the same rules apply: you can still move at a speed that degrades quality. No matter how skilled or experienced a team is, there is still a limit to how fast they can go without making major errors. That limit will be different for each team, but it still exists.
Anyone who pretends this limit doesn’t exist will be the first to outrun their headlights and crash through guardrails over a cliff.
Team vs. Individual Speed
Discussing project speed also brings up an important point: there is a difference between individual speed and team or project speed. An individual can increase their competence and speed, but that doesn’t always translate to being felt by the entire team or project.
A common scenario is when a really skilled and fast engineer starts producing work at such a blistering pace the rest of the team can’t keep up. This creates stress and tension on the team, which counteracts the speed of the single individual. It also counteracts that quality as the rest of the team is more likely to rubber-stamp the faster engineer’s work or avoid discussions on important details, which could lead to unchecked coding errors or design flaws.
The best way I’ve found for a faster individual to help make their team faster is a bit unintuitive: they need to intentionally spend more time helping others and creating a focus for the whole team.
Instead of the faster engineer working to just ship their work, they can intentionally slow themselves down by aiding in footing the ladder or helping to coordinate work across the team to be focused on the team’s current goals. This often looks like code reviews, sharing knowledge between team members, pair-programming, facilitating design conversations, and helping the team navigate making time-sensitive decisions. The best is when the more skilled engineer brings other engineers along to help them sort through tricky or time-sensitive issues.
The reason I think this works is that the more experienced engineer effectively helps up-level their entire team rather than working alone and calling it a day. If they are indeed faster than the rest of the team, they’ll usually be able to finish their own work without a problem.
Using Leverage to Move Faster
The last bit I want to touch on today has less to do with individual competence but with utilizing leverage to make yourself and the whole team faster.
As I’ve written about before, being strategic about organizing code, building and utilizing common patterns, and investing in a core set of languages or frameworks has an outsized benefit over time. Google has even recognized this, and that is why they have opted to organize their code around a large monorepo: The value of being able to discover and utilize existing patterns and tools is vital to giving leverage to engineers writing code.
This leverage is especially pronounced when it comes to helping teams move faster. If an engineer can leverage tools, abstractions, and capabilities created by expert engineers within a particular sub-domain, other non-expert engineers who need to interact with the sub-domain will be able to do so more effectively and quickly.
The quick conclusion today is that while there is truth to the idea that we can increase our speed by becoming really proficient and capable engineers, there are still limits to how fast you can go before quality suffers. Whether it’s due to the makeup of a team or the lie that you can always go faster, be cautious in how fast you try to go.
Instead of focusing on just being “really good” as an individual, invest in building strong levers through great code that compounds in value over time.
Whenever everyone can move fast, things get really good (and fun!).
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.