Layered engineering competence

Enterprise software solutions often consist of multiple systems, each responsible for different layers of the solution, such as presentation(frontend), application (backend), and infrastructure (data, integrations).

An interesting pattern I've noticed recently is that engineering skills and knowledge tend to cluster around these layers.

Often in teams, engineers spend more time working on one layer of the software versus the others. This leads to the development of competencies unique to that layer.

Presentation layer

Some engineers tend to work more on the presentation layer. Frontend engineers or UI engineers. Compared to engineers who work more on the backend, they get far more exposure to different UI designs. As a result, they develop an eye for UI design patterns.

When they look at a UI design, they see it in terms of components, modules, templates, and layouts.

When collecting requirements, they're asking questions about user flows, interactions, and UI states (empty, error, loading, and so on).

Once a UI design is implemented, they test different user flows, refresh pages, and navigate from different places.

Application layer

On the other hand, some engineers tend to work more on the application layer.

Compared to engineers working on other layers, they get more exposure to business processes. So they develop an eye for different workflows and system patterns.

When they look at a business process, they see it in terms of triggers, steps, branches, tasks, and workers.

When collecting requirements, they're asking questions about inputs, outputs, and business rules.

When testing workflows, they test different logic branches, try different inputs, and run multiple tasks in parallel.

Infrastructure layer

Sometimes there are engineers on the team who work more on the infrastructure layer.

They get more exposure to different third-party software systems and APIs. They develop an eye for different integration patterns.

When they look at an integration, they see sources, syncs, connectors, and transformers.

When collecting requirements, they're asking questions about data mappings, deduplication strategies, authentication flows, processing historical data, and so on.

When testing, they cross-reference data mappings, try different triggers, and create duplicates.

What I'm trying to demonstrate with the examples above is that each layer has substantially different nuances.

These nuances are unique to each layer and are developed by getting deeper into the domain.

Each one has its own tooling, best practices, and software design patterns.

Besides that, there's a difference in the lifecycle, from requirements gathering to testing.

Engineers working within their layer tend to perform better across the SDLC lifecycle.

They're better at eliciting requirements for their layer because they know what questions to ask.

They design better solutions because they've seen the design patterns before.

They implement faster because they're already familiar with the tooling and frameworks in the layer.

And they test more thoroughly because they know what usually breaks in this layer.

At the same time, assigning the same engineer to work on a less familiar layer often leads to subpar performance.

Because they don't see the things that someone with more exposure sees.

Excellence from one layer doesn't transfer to another.

Being aware of the depth of each layer helps align work with the strengths of each team member and nurture further development.