Hi! This week's newsletter is a bit different. I've suddenly run into some unfortunate build problems 😭 for the website and will need to share this week's article inline vs. on a separate post. Hoping to resolve these issues and return to normal in a few weeks!

Related: I'm taking a vacation, so I'll be skipping the second issue this month. I'll pick back up in April!

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:

• fast and high quality but also high cost
• fast and cheap but low-quality
• 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 and more to do 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!

Team-Building Exercise

This week's team-building exercise is about reflecting on whether there are ways you are inadvertently slowing your team down despite your own speed increasing. For example

• Are you overwhelming your team with too many pull requests?
• Are you focusing so much on your own work that you have blinders on?
• Are you relying too much on your own ability that you aren't investing in your team or shared tooling?

I've fallen prey to this trap myself, thinking, "I can move us faster if I just get my stuff done." While that can be true at times, the further you grow into your career, the more you need to focus on accomplishing through others.

Leading is much more about aligning on direction first and letting speed come through that alignment than the pure speed of one individual.

Here are some more resources from me to help you build better teams!​

Other Creators I Recommend

Daniel Schaefer Subscribe if you are a software developer that has the technical skills, but you're looking for opportunities to enhance your soft skills to advance in your career. Subscribe​

Looking for your next tech job? You're in the right spot. I'm Dr. Kyle Elliott, the founder and tech career coach behind CaffeinatedKyle.com, and I love giving away free resources that help to ensure your job search and career success. Join 7,435+ fellow job seekers who have downloaded my free Job Search Launch Guide. Subscribe​

113 Cherry St #92768, Seattle, WA 98104
​Unsubscribe · Preferences​

​

​