2 Types of Software Engineers Successful Product Teams Need

What do you picture when you think of a software developer?

Ok. Outside of the Star Wars, video game loving geek stereotype programming at midnight in the dark.

That’s a stereotype.. albeit, a mostly true stereotype.

But what else do you see?

Most people see either 1 of 2 types of individuals.

You will likely see a super friendly & creative person that is always making something new. They have many different hobbies & creative interests. They will play you a song on their guitar and then show you their lego fortress.


You may see a more reserved individual who is insanely smart but is a little moody. You don’t have any clue what they are discussing but you know it must be about time travel. You dare not ask for clarification due to the very real fear of looking dumb.

So the questions are “Which one is right and who is the better engineer?”

The answer is both.

Both types of engineers are common and successful in software development.

Good application developers come in many different shapes and personalities but I believe that we all naturally fall into 1 of 2 groups.

The empathetic implementor & the precise systematizer.

Implementors & Systematizers.

All product teams must have empathetic implementors and proven systematizers. Engineers who look at the product from the business perspective and others who look at it from the system as a whole.

You can’t lean too far one way or the other else you risk the long-term viability of the application as a whole.

What is an Implementation Engineer?

Implementors start with the business need.

They have a strong sense of empathy. Knowing the why of the application that is being developed.

They think of the user needs.

They want to solve real world problems and get bored with technical hurdles such as performance & security if it isn’t currently affecting the end user.

Implementors is the business’ best friend.

They seem part of the group and enjoy seeing the success of the users. They go out and party with you when you land a big sale or reach a milestone.

They align their values and success with the business.

How to Spot an Implementor

Implementors are creatives at heart. They would likely have a moderate to strong leaning in the Feeling category of a Myers-Briggs test. They are empathetic and are good listeners.

Implementation engineers generally take the unconventional route in their career. You’ll see them as freelancers and come from a self-taught background learning through projects, bootcamps and Youtube videos.

They like to tinker with different frameworks. Their side projects consist of many half-done user facing apps that have cool concepts but lack depth.

They are optimistic about your ideas and get excited how your product can have a positive impact on the world around them.

Strengths of Implementors

You cannot have a product without a good implementor. They see software as a means to solve a people problem.

They don’t like writing code just to meet a performance benchmark. Their code is purposeful and the end product is usable by real people.

As a business leader, you won’t need to have multiple reviews and clarifications with an implementor because your needs just “clicks” with them right away. They are empathetic and understand what you want.

You may believe that you should just hire a team of implementors.

You’d make a terrible mistake.

Weaknesses of Implementors

Implementors are a long-term liability when left on an island to themselves.

They write code to solve the problems and goals for now and can neglect the needs of the system as a whole. Over time, the code can become messy and difficult to maintain.

It can become expensive to manage and onboard new team members.

They neglect organization in order to continuously push out new features.

Product owners are happy with the short-term results but will grow frustrated as the costs of seemingly basic features begin to increase over time.

So what’s the alternative?

The Systematizer.

What is a Systematizer?

Systematic engineers focus on the platform & framework. They are big proponents of unit-testing and performance benchmarking. The application is their baby and it’s their job to nurture it to become a successful independent adult.

You’ll find most systematizers discussing the inner workings of the framework. They can become overwhelmed when you want to introduce a new feature into your product / their baby.

As a business or product owner, you’ll develop a love-hate relationship with your systematic engineers. You will lose your positive energy when discussing new features with them. Systematizers consider themselves ‘realists’ but are more likely to be pessimists when discussing changes to the product.

It is true that working with systematic engineers is frustrating but their word is also gold.

Your trust will slowly dissolve with an implementor because their ‘can-do’ attitude will lead to missed deadlines but you know when a systematic engineer says something will happen. It will happen.

How to Spot a Systematizer

You know a systematic engineers as soon as you talk to them.

You mention that you want to build a product and they begin using words that must be a foreign language. You have no idea what they are saying but you know that it’s important.

You may perceive systematizers as pessimistic, aloof or arrogant when discussing anything complex.

This is an incorrect assumption as they are thinking 5 levels deep.

System style engineers generally arrive from a traditional path compared to their implementor brothers. They are likely to excel in math and have computer science degrees.

They enjoy having their personal space and their baby to direct their attention. They excel when they get to see and manage their area of concerns whether it be in life or work.

Strengths of Systematizers

Systematizers love the product and the whole system.

They create the bones of the application that drives the long-term strength of the product.

The more systematizers can spend on the performance, security, efficiency of the product — The more your systematic engineer will appreciate you and build a tank of an application for you.

So what’s the problem?

Weaknesses of Systematizers

Don’t expect systematizers to build features without revisions and in any sort of short timeline.

You won’t be happy. They won’t be happy.

Systematizers need details.

If you need them to create a feature then they will require user stories, wireframes and prototypes. They don’t handle the ambiguous well because they will overthink it and take too long for simple user functionality.

They either neglect or don’t understand the business need. The whole reason why you want this application built.

Users and business requirements become an annoying maintenance task.

It is the mundane to-do items that pull them away from the more important priorities of building a powerful system.

Systematizers will create an overly complicated platform when left on an island. You will struggle getting a product to market and building a business whenever you solely have an engineer whose primary focus is the system.

So who should you hire and are implementors front end developers and systematizers backend?

Implementors and Systematizers vs Front-End and Back-end

Don’t be mistaken. Implementors aren’t front-end developers. Systematizers aren’t back-end developers.

You need both in the full stack of your application.

I really hate the idea of a front-end vs back-end developer. It’s a dated concept because you need both types of developers on every area of your product.

Implementors think about the user & business need. They can make really usable APIs just the same as a nice & flashy UI.

Systematizers can make your UI as fast as a jet while also securing your API and database at the same time.

It is a bad way to categorize developers as “back-end” vs “front-end”.

You have developers who think user first and others with think system first.

Will an Implementor Ever Become a Systematizer and Vice Versa?

The simple answer is no… Or at least, I haven’t experienced it.

It is my belief that you are born into a particular style of development based on your psychological profile.

I mentioned earlier when discussing Implementors that they would have a leaning towards “feeling” in their Myers-Briggs profile. This is in contrast to the systematizers whom I’ve experienced that will lean more towards “thinking” in their profile.

I, myself, am a natural INTP by definition but the T/F is always in the middle. I’d consider myself an implementor by nature.

Classifying one as an implementor vs a systematizer isn’t always as straightforward as having someone take a Myers-Briggs assessment.

People are always more complex than any personality test but it does show that we are born with certain ways of understanding the world.

I don’t see implementors switching to be systematizers and vice versa.


The Hallmark of a Senior Software Engineer is Growth in Their Opposite Context

The larger answer is that a senior software developer should strive to become stronger in their opposite context.

I don’t expect a junior implementor to know the best performance and security best practices when hired. The opposite is true for systematizers. I expect that they will need very focused user stories and potentially several rounds of review.

But this isn’t the case for a senior level engineer.

A senior level engineer will always have a personal leaning. They know their strengths and excel at them. But they also know their weaknesses.

And they work hard to limit and overcome them.

Implementors should be your first hire that follows the lead of a community systematizer

So the question becomes, “Who is the right hire for you?”

If you are a startup looking for the right technology hire, you only have ability to hire 1 person. You should start with an implementor as they can build out prototypes that can get your product into market.

But make sure they aren’t working in a silo.

Whether they like PHP, Node, Ruby, Python, Go or whatever, make sure to ask them what frameworks and who they follow?

They need to follow a community and leadership bigger than themselves.

This is true for all application developers but extremely important for your startup. You don’t want to have 1 developer that codes in a silo.

You need to make sure that they are following the proven ground of a systematizer that has built a solid framework.

Your startup’s second hire, the systematizer, will thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *