Photo by Gustas Brazaitis on Unsplash

What Is Engineering Excellence

Authors note: by Engineering here I mean Software Engineering as I am not qualified to speak on other schools of engineering.

Introduction

In a previous article [1] I explained why just catching bugs is not going to lead you to a high quality product. I also explained that what level of quality you need in a product depends on what phase the company is in and that there’s a “Maslow’s hierarchy of needs” when it comes to product quality. More recently, I’ve come across an excellent graphic from ProductStack that describes this somewhat:

ProductStack approach (see [2]), credit: ProductStack

As you can see, in a product’s life-cycle, there is a discovery phase and a development phase. In the discovery phase we are trying to figure out what to build (in product management speak: finding the product-market fit). In this phase, the team or company has limited budget and time to figure out what is the product that users will want to use. The team just needs the level of quality of the product so as not to annoy test users and perform validated learning to refine the MVP (Minimum Viable Product). However, once the product-market fit has been determined, the objective shifts from figuring out what product to build to building the product right. Somewhere during this transition, the engineering team will have to reach the stage of sustainable development and in order to achieve that, you need Engineering Excellence.

What is Engineering Excellence?

In [3], Tonya Mork uses the analogy in sports to arrive at her understanding of the term. In summary, engineering excellence is:

1. Based on the ability to deliver results
2. Progress is earned through continuous work from idea to implementation and beyond
3. “wins are measured in our performance to understand the client’s problem, the formulation of the solution strategies, and then ultimately through the entire prototype, build, test, and process”

In [1], I also used an analogy, that of designer leather goods, to explain how craftsmanship and attention to detail produce products of high quality.

In [4], Kevin Scott, ex-VPE of AdMob and LinkedIn described it as having the 3 components:

1. How We Make Things
2. How We Operate Things
3. How We Function as a Team

In the same article he also talks about the importance of the “How” instead of the “What”. Engineers have a tendency to focus on the “What” (what tool to use, what language) instead of the “How” (How are we going to ensure that our codebase stays clean as we scale from 20 to 100 engineers?). The “What” may change from project to project. The “How” should not.

Lastly, in [5], Martin Buberl, CTO of Avrios, lists down 8 questions on strong engineering culture:

1. Are you innovative?
2. Are you agile?
3. Are you open?
4. Are you transparent?
5. Are you diverse?
6. Are you good?
7. Are you social?
8. Are you happy?

Jiro dreams of sushi trailer. Credit: YouTube

In the pursuit of understanding the mind of the crafts-person, I have looked elsewhere as well. One source of inspiration is the movie “Jiro dreams of sushi” [6]. In there, sushi master Jiro Ono constantly hones his craft, not just how the ingredients are sourced and prepared but also pays close attention to his customers. He notices subtle cues like whether they are left or right handed, their disposition at the time of the meal, their reaction to the dish placed in front of them etc. This all to craft the perfect meal.

The Repair Shop Trailer. Credit: YouTube

Another source that has inspired me is “The repair shop” [7]. This BBC TV series (also found on Netflix) features various crafts-people who are experts in their field (eg. horology, ceramics, upholstery) who restore old family heirlooms to the delight of their current owners. Such items are usually passed down several generations and hold strong sentimental value. A few things always stand out in each episode for me: (1) the crafts-people always ask the owners what would it mean for them for the item to be restored (2) the attention to detail and the deep knowledge of not only their craft but also the background history of the items they are working on (3) the delight of the owners when they see the restored item and how much satisfaction it brings the crafts-people who worked on the restoration, not to mention the pride in their work. In one episode, Steve the resident horologist restored a clock to pristine condition and later reflects on his work, saying that “hopefully in 50 years time, when it (the clock) needs to be repaired again, the next person would find that this repair was done well”.

From these, and my own meandering experience in software engineering, I have come to my own definition of the subject at hand:

Engineering excellence is the pursuit of being excellent at the craft of engineering, being both efficient as well as effective in delivering delight to customers and in the process deriving pride and satisfaction from the work and the finished product. It is an endeavor, not an end goal and it spurs us as engineers to wake up each day to just build better and become better at our craft.

That is at the individual level. What about at the organizational level?

Engineering excellence is also about identifying obstacles that impede engineers from doing their best work and the measures that can be put in place to assist and encourage them to be excellent and to strive for excellence.

The four pillars of Engineering Excellence

Based on the above definition, we can now identify the key aspects or what I call “pillars” of Engineering Excellence:

1. Craftsmanship
2. Effectiveness
3. Productivity
4. Happiness

Craftsmanship

This is at the very heart of excellence. It is about our skill-sets and how well we build our software, how much thought has been put into the design, implementation and testing of the product or system. Some attributes come to mind:

• How confident are you that your work will stand up to the scrutiny of your peers?
• How do you stack up with your peers in the top-tier technology companies in terms of your craft?
• Are you as an engineer proud of your work? Would you feel embarrassed if it were open sourced?
• Do you keep yourself up to date with current technologies and the state of the art of your field regularly?

At the organizational level, we are looking at:

• Does the organization provide the resources for engineers to upgrade themselves and hone their craft?
• Does the organization provide the mechanism to reward or celebrate engineers for their craft and for their pursuit of honing their craft?
• Are the best in their craft providing apprenticeship, mentorship and counsel to the rest of the organization?
• Do leaders recognize the best in terms of craftsmanship in their teams?
• Do leaders regularly update themselves with current technologies and the state of the art at the level that enables them to make good decisions?

Effectiveness

This has to do with problem solving as well as project management and execution ability. Some aspects:

• Do you have the confidence to execute commitments on time and on budget?
• How well do you estimate effort when scoping out engineering tasks?
• How well do you identify technical and project risks and communicate them effectively?
• How well are you able to isolate root causes of issues?
• How well do you use data to make decisions, analyse impact and communicate findings?
• How well do you hand over your systems? Do you design and document your systems so that you are able to move on to more interesting projects seamlessly?

At the organizational level,

• What are the obstacles at the team or organizational level that engineers face impeding them from delivering on their commitments?
• What are the sources of inter and intra team friction that obstruct team cooperation?
• Are software contracts communicated clearly and enforced?
• How effective are leaders in building and fielding teams for tasks and projects? Does the organization provide them with the tools needed to do this?

Productivity

This has to do with the efficiency in problem solving and execution of tasks. Some aspects:

• Are you spending more time on the things that matter rather than the things that don’t?
• Do you have sufficient, uninterrupted blocks of maker time to design, build and test?
• How quickly are you able to zoom in to the most critical issue at hand, be it troubleshooting a bug, isolating a design flaw or identifying an “unknown unknown” in requirements?
• How good are you at getting things done right the first time?
• Do you document your work and systems or make them self-service so that you don’t have to be constantly bugged to support it?

At the organizational level:

• Does the organization have the infrastructure in place so that much of the run-of-the-mill tasks are either automated or self-served? Does the organization have the culture of automating routine tasks?
• Does the organization have the infrastructure in place to enable and empower engineers to troubleshoot issues in as short a time possible?
• Does the organization create too much distraction that engineers have difficulty establishing blocks of uninterrupted maker time?
• Is key technical information easy to locate and navigate?
• Do leaders shield their teams from time wasting and potentially highly interrupting activities?

(AI is emerging as a force multiplier ie. a tool that allows engineers to offload some of the mundane tasks via intelligent automation. I describe some of that in [10]).

Happiness

Napoleon once said, “an army marches on its stomach”. Similar to this, happy and happily engaged engineers are key to the success of any business that has software developed by its engineers as its core. So how does engineer happiness relate to Engineering Excellence? Well look at our definition:

“… delivering delight to customers and in the process deriving pride and satisfaction from the work and the finished product” and “… it spurs us as engineers to wake up each day to just build better and become better at our craft”

It is quite clear that if engineers are not sufficiently engaged and supported, there is no way they will be able to derive satisfaction in the work and the finished product or wake up each day to build better and be better at their craft. Also, in the global tech talent grab, great engineers are always in demand. You can’t have Engineering Excellence if your best engineers are frequently being poached away.

To this end, some of the questions the engineering organization and leaders need to answer are:

• Do engineers feel a sense of ownership of the system they are building or maintaining?
• Do engineers feel part of the team they belong to and are able to contribute to the success of the team?
• Do they (the engineers) agree with and support the technical direction of the team and the engineering organization as a whole?
• Do they feel sufficiently intellectually challenged with the work they are assigned? Or are they overwhelmed?
• Do they have a creative outlet to try out new ideas eg. hackathons, side-projects, that are supported by the organization?
• Do they feel sufficiently compensated?
• Do they feel that they are sufficiently supported both technically and non-technically by their team and the larger engineering organization?
• Do their leaders provide timely and actionable feedback for their work?
• Do they feel they are able to grow and are supported in the growth of their career in the team they are in and the larger engineering organization?

(I also recommend reading Christopher Steiner’s article “Keeping Engineers Engaged And Happy Is Critical — Here’s How To Do It” [8] on this topic if you’re just starting out managing engineers).

Why does this all matter?

Remember at the start of this article, I mentioned that as the engineering team is transitioning from the “Build the right product” to “Build the product right” phase of the product life-cycle, it has to also transition to sustainable development. This means shipping products (or newer versions of the product) that do not frustrate users and do not burn out your engineers.

In [1] I wrote about the stages of a company/product’s growth and explained that this is usually the stage where the company starts getting more paying customers and at an accelerated rate. This means having to build a customer support team and dealing with customer complaints. If the shipped product is unusable due to bugs and crashes, you are going to have a huge customer support cost on your hands. This then leads to engineers having to spend most of their time in fire-drills fixing critical bugs and pulling long hours. This is not sustainable and very frequently leads to burn out and engineers leaving the company. This could possibly snowball as the workload leftover by the ones who have bailed falls on the existing team.

For most teams, the logical approach is to build up a Quality or Test team. However, as I explained in [1], while this is necessary at the time, it is just a stepping stone to achieving sustainable development (hence the title). A culture change needs to happen. Where once it was getting features at all costs to see what sticks (including incurring Technical Debt), the next phase requires engineering maturity, in other words Engineering Excellence.

Why is that? Well catching bugs is “after the fact” ie. the bug has already been introduced in the product. Yes, part of the quality process is process improvement which includes post-mortems but again, this is “after the fact” and comes with the opportunity cost of building new features. We need to find ways to bake in excellence in the engineering process and the product.

To make this a little more concrete, let’s take a cursory look at how the pillars of Engineering Excellence can be applied to that end (this is just an illustration and is by no means complete):

1. Craftsmanship — by having deep knowledge of what great software looks like, engineers are able to design and build the system so that it is flexible, maintainable and testable. Good, strong coding practices eg. code reviews, unit tests (see [9]) also ensure that bad code doesn’t get into the code base.
2. Effectiveness — by estimating costs, managing projects and identifying risks well, the team is able to deliver projects on time and on budget and at the same time keep taking steps forward, systematically reducing technical debt accumulated in the previous phase.
3. Productivity — by ensuring engineers are not wasting their time on needless work and making the right investments in force multipliers (eg. CI/CD pipelines with good test coverage are a huge force multiplier) engineers are able to do more with less.
4. Happiness — any loss in experienced engineers would cause a hit in productivity and effectiveness of the team. It is crucial to keep engineers fully engaged and happy.

There is much more to write about on the topic of this “crossing the chasm” — transitioning the engineering team from “build the right product” to “build the product right” phases and I look forward to sharing my thoughts on the subject in a future article. It is by no means a trivial endeavor and there will be mindset shifts and/or key personnel changes necessary in the process. It is as the popular adage goes “what got you here won’t get you there”.

Conclusion

In this article I have provided (at least what I consider to be) a usable and easily understandable definition of Engineering Excellence — both from an individual engineer’s perspective as well as the organizational support structure needed to enable it. From that definition I have derived 4 “pillars”: Craftsmanship, Effectiveness, Productivity and Happiness.

I have also touched on why Engineering Excellence matters: because to build products right, you need sustainable development and that requires Engineering Excellence.

I hope you have found this useful.

References

[1] You Can’t Fix Quality Just By Catching Bugs, Heemeng Foo, Medium, Oct 2020, https://medium.com/swlh/you-cant-fix-quality-just-by-catching-bugs-ddc01d900474

[2] Product Management Approach, ProductStack, date unknown, https://www.productstack.com/approach/product-management-methodology

[3] What is Engineering Excellence, Tonya Mork, Aug 2018, https://hellofromtonya.com/blog/what-is-engineering-excellence/

[4] How I Structured Engineering Teams at LinkedIn and AdMob for Success, Kevin Scott, 2015, https://firstround.com/review/how-i-structured-engineering-teams-at-linkedin-and-admob-for-success/

[5] The Culture Test: Eight steps to better company culture, Martin Buberl, 2015 — https://martinbuberl.com/blog/the-culture-test-eight-steps-to-better-company-culture/

[6] Jiro dreams of sushi, David Gelb (director), 2011, available on Netflix

[7] The repair shop, BBC TV, 2017–2020, available on Netflix

[8] Keeping Engineers Engaged And Happy Is Critical — Here’s How To Do It, Christopher Steiner, Jun 2017, https://fundersclub.com/blog/2017/06/08/keeping-great-engineers-engaged-critical-founders-heres-how/

[9] Unit Tests and Code Reviews: the bedrock of software quality, Heemeng Foo, Sep 2020, https://medium.com/dev-genius/unit-tests-and-code-reviews-the-bedrock-of-software-quality-9a23cd24558b

[10] The Case for AI in Software Testing, Heemeng Foo, Sep 2020, https://medium.com/dev-genius/the-case-for-ai-in-software-testing-5aba64e62d0f