Stop Hiring Software Engineers
Consider product engineers
Ok, I know, the title might sound bold but this article is not about the outsourcing of your development team or increasing consultants, not at all.
I recently read several articles about the “10x Developers”, and everything I read was very insightful; anyway what I read mostly has a take from an Engineering POV — they often talk about junior vs senior, tools, removing code, competencies, etc. all valid points, but I would like to give a slightly different angle.
The Product Engineer
There’s a subset of software engineers: these are (software) product engineers and most probably are the ones you should really look for.
Product engineers (PEs from now on) are easily identifiable in the interview process, we will discuss later some common traits.
As software engineers we rarely work in a technological domain; we mostly end up in other domains, improving the technology to support the business, among the others we can mention FinTech, Automotive, Insurance, Aerospace, Medical, Travel, eCommerce, etc. and, when a software engineer moves in a new domain brings with him a toolkit of competences: the programming language, the algorithms, the frameworks, the tools, the patterns, etc.
Most probably during an interview, you assessed if someone is proficient in using Scala if that’s your company programming language, or if they know Kafka, Redis and Cassandra if you are using them; it turns out that very often you end up hiring someone that has the skills the technology team needs. Congrats, you most probably hired a great software engineer for your team, but maybe it would have been worth checking if there were PE traits.
So what’s a PE? It’s not about juniority or seniority, and it has nothing to do with technology: it’s all about product development and ownership. A real PE understands that his main focus has to be on product improvement, so will focus on the domain trying to understand the dynamics, the processes, and the core concepts.
Deliver Value!
PEs are obsessed with delivering value; they have (or will gain) full ownership of the technological product and the associated processes.
PEs won’t really care about migrating from one technology to another unless there’s value for the business behind this.
PEs don’t think in silos, they want a full picture to understand where to improve. They will go and talk with every other function in the company: from Marketing to Customer Care in order to gather full product knowledge (yes, they will even if they work in DDD with bounded contexts).
PEs will take care of the production environment behaving like there’s nothing more important than that: stopping any other activity in case of an incident.
PEs love the Pareto principle:
Ask a Lot of Questions
Imagine having such an entry in the backlog, tagged as technical debt:
“Reduce the execution time of function X by one-third through indexing of K”
Is this important? Is this “real” technical debt? Any engineer will most probably tell you that it’s important to fix it, because as engineers we are obsessed with improvements, refactoring, etc.
A product engineer will most probably try to understand if it delivers value
“is this time reduction having a positive impact on any of the stakeholders?”
“Will this make the life of our customers better, reducing their waiting time?” “Will this reduce the platform cost significantly?”
If the optimization is purely technical then it’s the minimum priority
Don’t get me wrong: PEs care very much about concepts like maintainability of the code, design principles, and refactoring — but they will always balance each and every improvement towards the aforementioned “value delivering”.
“Is this change an enabler?”
“If we move to this pattern will we be faster in accommodating other business requirements?”
My 2 Cents: 2 Lines of Code
I have been working in several industries, writing thousands of lines of code, and developing several products and features I am proud of, anyway the following two lines of code had among the biggest resonance box:
if (text.trim().length() <= 2)
text = ""The most junior developer, even a student approaching programming for the first time, would have been able to write this. A bit of context.
I was working in an Online Travel Agency (OTA), and as a team, we were taking care of the checkout phase of flights. One day I organized a call with the customer care team, trying to understand their pain points, and the chief of customer care prepared a slide with all the problems they were facing: one of the entries was “manual bookings”.
As an OTA your aim is that, whenever a customer is buying something, the process of completion towards the airline or any other third party does not require any human intervention. Some reservations, anyway, end up in manual mode (eg. there’s no more availability, the price increased, etc.) so you need an operator to take care of that. 15 percent of those manual bookings, were tagged as “Special requests: wrong input from end customer” — on the webpage, there was a text box with the caption:
“Write here any special request about your flight”.
When you book a flight you might have some special requirements, like transporting an animal or valuable material, so you want someone to confirm that you are allowed to do so before purchasing the ticket.
Long story short: some users were confused and they were writing in the text-box “NO” or they were adding a “.” or a series of white space.
The logic to put a booking into manual mode was: “If there’s content in the text box, then assign it to an operator”.
Immediately after the meeting I went to my laptop, added the 2 lines of code, introduced a couple of tests to validate, and released in production. One month later I was invited to an executive meeting, where I was awarded for having solved with efficiency a huge company problem, saving also a lot of money and providing a way better customer experience.
Yes, these 2 lines were doing what follows:
- Reducing the number of manual bookings
- Improving the customer experience, having an immediate confirmation after the checkout was completed
- Reducing the risk of price increase or unavailability given by the human processing time
It’s Not My Problem, It’s Someone Else’s Problem
Before the end of the meeting I tried to understand with the chief of customer care if she reached out to anyone in the past to solve such issues, I was really surprised by the answer! “This is not an engineering problem. This is a user-experience problem, the UX team should take care of this”, she got back, but when she tried to reach out to the UX team they were redesigning the full checkout, so there was no space for any improvement on the current design.
A company problem has been there for months without anyone tackling it.
Those two lines of code remained online for a few months, when the new design was released the problem was settled using a checkbox:
“click here if you have any special requirements about your flight”
Clicking the checkbox would have made the text box appear.
The Difference Between Scopes and Boundaries
The aforementioned example set up the space for distinguishing between scopes and boundaries.
Is the solution to the problem outside of the pure engineering scope? Yes, there’s no doubt.
Is the “correct” solution, from a company perspective, acceptable?
I personally don’t think so. Waiting a few more months for UX to solve it would have cost a lot from every perspective, but to engineering, it took 30 minutes for 1 person to fix it. The boundaries of a person are way bigger than the scope of the role they’re involved in, doesn’t matter if they are in software development, data or test, or platform engineering. It’s a mindset, where you always focus on your product and your customers, rather than on the technology and the scope. This concept is valid for every function in the company, not only for technology.
10x Engineers
During my 15 years in the field, working in several industries, I met less than 30 people I could describe as Product Engineers.
I’ve met amazing engineers, some of them were technically amazing and way more capable than any PE, but no one of them has ever been close to delivering value as much as a PE.
I think PEs are the 10x engineers.
Should We Really Stop Hiring Software Engineers?
It depends: everything has to be contextualized.
If your company is developing a product you should probably look for the PE traits, anyway many developers chose this career because they love technology and they’re not really interested in any other domain. They want to build pipelines, set up infrastructure, do automation, and work with bleeding-edge technology stacks.
In many realities, these software engineers are working either in the Platform space or in the “Development Experience”, doing purely technical jobs trying to improve the life of developers.
How we changed our interview process
Finding PE is very hard, so you should not reduce your initial funnel.
At iptiQ, my current employer, we changed our interview process to have the best chances to find top players:
- We don’t request any specific technical knowledge (no Spring Boot, DynamoDB, Redis, etc even though we work with this stack)
- We accept developers coming from any programming language, even if our codebase is written in Kotlin (we do a coding test asking the person to solve it in their favorite programming language)
- We assess general problem-solving skills
- We look for the traits of a person caring about the product, asking questions outside of the technological space
We do this because we think everybody can learn a new programming language or a framework, but it’s very hard to teach how to become a PE.
