How treating everyone as customers leverage your engineering outcomes
Hi engineering folks, as fellow engineering I doubt you will be interested in this topic. As a programmer our job is to code and deliver features, our time already full there’s no time to think about this.
- I’m an engineer why should I care about this?
- I’m only a junior engineer, it should be my seniors to learn this!
- I will pursue an individual contributor/technical path, I don’t want to deal with people.
Hey, do you think being an engineer and focusing most of your time on code will free you from this responsibility? No! Better yet it will boost your leverage by having clear problem space and measuring your impact.
*yes this can also boost your career
Success is not delivering a feature; success is learning how to solve the customer’s problem.
- Eric Ries, author of lean startup
This is an engineering topic why lean startups? Relax, if we took a different angle feature can be any output we do bug fixing, refactoring, code improvement, code feature, etc. Customers? like the title said everyone is a customer.
Who is our customer?
It is your peer, supervisor, direct report, the one that uses your services, CS, products, Ops, and it’s literally everyone.
Why are those our customers?
Let’s start with something in common “expectation” yes, they all have expectations for us and our services. They will always come to us when there’re issues with our services, when they’re not understanding what happens, or when they need us to do something.
Our services, this you might be asking. This is everything we’re expected to do, every company have its own expectation and it is different at each engineering level, but one thing is for sure coding is a basic neccessities Engineering is being paid for their problem-solving skills and at a more senior level, we are expected to widen our impact on the company and vary how we do it.
In daily process of our problem solving there are also things we’re expected to do
- Maintaining our technology services (eg: fixing bugs, improving latency, scaling) within SLAs
- Analyzing issues, find out how big is an issue impacting our services
- Breakdown requirements into technical implementation & capacity planning
- Sharing knowledge and growing teammates' skills.
- Able to gather problem statement & scope, define an appropriate chunk of task based on goals, priority, and critical scope
Yes in those processes it often interacts with our “customers” and if we don't meet their expectations or they need our services they will come to us.
How is this leverage engineering outcomes?
At a high level, the one who wins the customers wins everything. I remember my mentor who is ex-Airbus engineer once said
You have to treat your surroundings (up, peer, down) as a customers and deliver 120% to become their top of minds then opportuntiny will open itself.
At the implementation(technical) level, this will change your mindset and thus affect how you do things. Like how?
If you were an engineer like me. I was full of ego and think that what I want is the most important thing to do like refactoring, using updated technology, implementing best practices, fixing bugs, etc.
I was never a listener, when people say something that is not aligned with my priorities or how I do things, I tend to skip their thoughts or become defensive of my own priority.
When I think of everyone as customers, it changes my mind that I was not the center of the universe it is them (customers). I listen to their thoughts and try to understand from their point of view. I was the one who have the responsibility to maintain my services giving my customers my best delivery. The implementation was vary but the problem & measurement is clear.
As this is one of the key points to grow as an engineer in Lau’s Effective Engineer book.
How are we doing it?
This one actually very easy, the hard one was changing the mindset.
- Listen and assume good intentions with every discussion you have.
- Understand and align what people expected of you, and what this person needs you to do.
- Put a clear definition of what action (eg: estimate) you will take and get back to them, don’t ever ignore the customers. This will give them relief and feel that you are working on their problem.
- Be good, mind your communication or how you talk to them.
- Frequently check your customer's health (eg: error rates, NPS, latency) through metrics or surveys.
- Acknowledge and don't be defensive.
The don’t do
Not being rational and too focused on the customers you will lose your own road. Remember we have to listen but DON’T ALWAYS DO WHAT THEY WANT. A lot of customers don't really know their problems, so we need to be careful in analyzing their issues with our services vision. In the end, you own your services, you are the one who defines how you want customers to feel.