Excellence As An Engineering Value

Introduction

This interview article explores “excellence” as a core value in engineering.

Is excellence the North Star of engineering?

And what happens when limitations of time and expectations create a barrier to achieving excellence at work? 

A Conversation With Hussain Abbas, The Director of Engineering At Axelerant

Many techies I've come across call Hussain Abbas a "tech wizard."

And someone who's got his team's back.

For the past 20 years, Hussain has chased excellence through his work.

Putting on every kind of hat in the industry—trainee coder, project manager, team and service area lead. Business owner. Director.

A regular contributor to Drupal, Hussain’s work had a singular impact on the migrate module of Drupal 7 to Drupal 8.

But he is also a recovering perfectionist—who had to learn to channel that zeal for his work towards something positive.

Something that comes a little closer to excellence every day.

Why Are We Talking About This Value?

Apart from the sheer importance of the topic in any engineer's life, there's a backstory behind this article.

Some time ago, I published this piece on enthusiasm as a core value at Axelerant and how team members embraced it. 

(The other two core values are: Openness and Kindness.)

I had compared "enthusiasm" and "excellence" as values and sided with enthusiasm as the clear winner.

It was based on an earlier discussion from 2018 to replace "enthusiasm" with "excellence" as the organization's core value.

Now, at this point, you may be thinking: Great! One more organization is talking about its make-believe values. Who cares?

As it turned out, many did. And no one cared more than Hussain.

This took me aback. 

And it made me curious—why would a Director, responsible for so many people's success, care about this comparison so much?

I had to know.

The Importance Of Excellence As An Engineering Value — The Interview

I asked the following questions to Hussain Abbas during our interview.

What do you mean when you say excellence as a core value in an engineering context?

I'll talk a little bit about core values first. 

One of the reasons we have core values is that it helps us make critical decisions. It's not just words on paper. 

If you meet with a seemingly impossible decision, that's where core values help. 

Because you look back at your values, at your principles, and then decide: okay, if we make this decision, select this option, are we living up to our core values?

Because each decision is a trade-off, there is no perfect decision anywhere. We live in the real world.

And over the years, I have realized that we can use excellence as a value, a yardstick, to measure our decisions. 

For example, a straightforward engineering decision for a customer's project—hypothetically—where we are attracted towards convenience. 

But we want to do the right thing for the customer. And that's where excellence as a guiding value plays in.

At Axelerant, we have always prided ourselves on being customer-centric. 

We focus on delivering value. Delivering happiness. I mean, both internally and externally, because it can't be an isolated exercise. 

You ensure happiness for your customers by ensuring it for your team members. 

I'm talking about building practices around excellence. 

We handpick our team members based on their enthusiasm for the technology—we are an engineering-heavy organization, after all.

They will stay happy if we promise them we aren't compromising on excellence. And that also means that we're going to deliver the best possible solution to our customers.

I want to hear about your personal experience. How has this value impacted your life and work so far in your journey?

Like many engineers, I started on the path of being a perfectionist. I would not make compromises. 

I started my career writing x86 Assembly. And I frowned upon anything very easy to do in computer programming. 

This is a 20-year story, so I will skip the middle sections. But yeah, that's where it comes from. 

The things that make programming an art, I think that's what draws me towards excellence.

Because art has that subjective quality. It's really in the eye of the beholder. Yes, there are certain hygiene factors related to art, but beyond them, it's purely subjective.

In other words, we are at the crossroads of programming and art.

So how do we make them intersect? We want to make every programmer and developer feel valued. 

Make them aware of the artisans that they are. That they are creative people bringing their creative juices to work. 

And we also want some degree of predictability—that we deliver tasks on time. 

I think excellence captures the intersection quite nicely.

Excellence is subjective. We're not talking about perfectionism over here. We're talking about something that's still subjective, which can still be beheld as artwork. 

Where there is still scope for creativity. And flaws. 

So yeah, that's my story towards excellence: starting from perfectionism but then trying to meet it at the crossroads of engineering and art.

Why do you think the value of excellence is important for engineers specifically?

It's not a question of making it important. 

I believe programmers and all developers want to deliver the best possible solution. 

The challenge arises when we try to deliver the solutions within the constraints we have set on ourselves. 

Because realistically, when we want to deliver something, we face constraints like time and cost. 

So it's not a question of conveying to engineers that excellence is something that you strive for. 

It's our natural state. 

Various factors suppress that state along the way—challenges and constraints.

And by talking about excellence as a core value, I'm reminding them that it's okay to take risks. So that they are not tethered by the constraints and their natural state can flourish.

We aren't talking about avoiding the constraints altogether.

We understand our business context, we understand our customers, we know that a feature delivered too late may not be helpful at all. 

You have to read the situation. You have to understand the context. But it's okay to take time; because excellence takes a little longer. 

As engineers, we need to know when it is prudent to spend that time and when it's not. 

Can you share an instance from experience where you took the longer route to chase excellence?

I'll pick up an example from my days when I moved into a management role—around 2017. 

I went through the same dilemma that all individual contributors go through. 

We are wired in a way where we deliver a task, and we move on. And we look at the system from a purely technical viewpoint.

And now, suddenly, I was thrown into management challenges. 

There was a lot of support available here at Axelerant. But I didn't know how to begin.

There were other managers here as well. But I was the first engineering manager here. So there was nobody else in my role that I could emulate.

I picked it up from a lot of different places. Ankur Gupta (Axelerant's CEO) was my reporting manager even at the time. So, a lot of help, a lot of support, a lot of leeway came from him. 

And then there was Mridula Ujjwal, the Director of Coaching today.

And our people and culture allowed me to go into a luxurious state of learning management.

I started looking up different books, different resources. 

Until I found one which resonated with me—it's a community of leaders on Slack, quite well known. Rands Leadership Slack. 

(You can join the Slack channel by following these steps). 

Most of the leaders in that community were from product companies. And their management style didn't directly apply within an agency or consultancy like ours.

But I could experiment and incorporate many practices; customized to fit us.

One example is one-on-ones. We have had one-on-ones even before that. But after joining the community, I saw them in a whole different light. And those are my one-on-ones, even today.

A typical one-on-one looks like a monthly event in most agencies, at least at Axelerant. And with a fairly fixed structure with clearly outlined points.

But my one-on-ones are entirely flexible. 

I don't have any sections at all. And I run them weekly, or bi-weekly if somebody's not comfortable.

Are you measuring excellence in engineering at Axelerant? And if yes: I’m interested to know—how?

Core values are not defined to be measured. 

And if a value can be measured, it has the scope to be stronger because core values aren't goals or targets.

The chief use of core values is to make decisions. 

And I think it's not a measurement of the value, per se, but a measurement of ourselves. Are we living up to our core values? 

And to do that, you have to look at our decisions. 

The decisions we make organization- or team-wide. Because values can be for teams as well.

We need to introspect through our decisions—and actions—if we are living up to our values.

For example, there is an easy way to get things done in a project. And a little harder way, which is going to generate long-term value.

The simple answer is, yeah, do the harder thing. 

But that's not always possible. 

You know, there's always a nuance in that decision. There are a lot of different factors to consider. 

Whatever decisions we reach in each scenario tell us whether we are living up to our value of excellence.

That is a measurement we can have.

What kind of benefits can a person expect to see from consciously following this mindset or this value in their work?

The most significant change, or the only change that matters, is that person will find that they're happier at work. 

As I said, excellence is natural for almost everyone.

It is only when people get used to the constraints that it becomes a question: Okay, am I opting to follow excellence over here or not?

So if they're living up to the value of excellence, a person can find fulfillment in themselves.

What does that look like in real life?

When one comes to work every day determined to do their best. Get things done that need doing. But not mindlessly. Make conscious decisions along the journey, and live that experience. Live the day.

How do you make a conscious decision?

By asking, is this the right thing to do now? Is this the right approach? Should I take the longer route? Or is this a situation where I can take a shortcut?

You realize that, okay, whatever I did today, was the absolute best I could do, given all the information I had and the constraints I'm experiencing right now.

What are some main constraints engineers face when striving for excellence in their work? And how can one overcome them?

Constraints are a part of life. 

There's no need to put it differently. 

To deal with these constraints, you must understand why they are there.

Generally, we have a blanket answer for all constraints—yeah, it's life, and constraints will be there. Or—the customer says so. 

Like the adage, "The customer is always right." We no longer practice that here.

Generating value for the customer is important. That is the right goal to pursue. 

Customers often don't know what they want. As experts in the field, they want us to guide them properly.

There is another dynamic at play over here. But it's merely an extension of the customer mindset. 

It's the project manager mindset. 

You have to realize that project managers are like customers for juniors starting in this industry.

They very rarely interact with customers, unlike in Axelerant. The situation is changing, and it's for the better.

So there are these three facets. 

• One is the value that customers are looking for 
• There is a project manager in between. And for many engineers, it's the only thing that they know
• And then, of course, there's the engineer's perspective itself. Understanding the system's technology, what's possible, what's easy, what's not easy, what's readily available on StackOverflow, and when they can't use ChatGPT to write the code

These factors essentially make up the constraints. 

As an engineer, it is crucial to understand the reasons behind constraints. 

Can you share a real-life example of these constraints at play?

Sure. 

Let’s say a security update may require a quick implementation within a short SLA (service level agreement) window. 

It needs to happen fast.

So, along with that security update, if you're trying to implement a time consuming technical debt, it is irresponsible.

On the other hand, if the technical debt is not taken care of, the security update can't happen. Because if we perform the security update, technical debt might break the system.

Now you have to look at all the possible ways to move forward.

There must be constant communication between the stakeholders: that this is the situation right now. 

Again, it's not about blame. It's about the real reason: this update is being held up. What do we do? 

Option one: hold off on the update. These are the known risks if you don't patch the update immediately. Are we ready to live with that? 

Option two: apply the security update. But it will break this particular functionality in the system. Are we okay with that? 

And then the timelines for each also factor in. 

Because we want the system to return to normal as soon as possible.

That is how you deal with these constraints—by communicating with the stakeholders and making conscious, logical decisions. 

We already have enthusiasm as a core value in Axelerant. Is excellence going to be a subculture within the existing core value of enthusiasm? 

I'm mostly indifferent to the discussion of making excellence a core value. 

When making a choice, we don't think of enthusiasm and then excellence. We only ask ourselves: is this the best thing I can do now?

Within engineering, I'm deriving more concrete examples or more concrete behaviors from this label: excellence. 

And we are looking to adopt them as core principles within engineering. 

But these behavioral examples essentially point towards delivering the best value. 

So, would excellence be something that falls under enthusiasm? In a manner of speaking, why not?

But I still see excellence as something discrete.