Want more dependable feature delivery, happier developers, increased velocity and performance, all at a lower overall cost? Consider horizontally aligned teams utilizing Feature Guides.

When it comes to software development there really are only two ways to organize your team; Full Stack (vertically aligned feature teams), or domain based (no, not heap).

Full Stack

Jack of all trades and (usually) master of none

Vertically aligned development, is seductive. In theory, it puts into the hands of the Product Manager, direct control of all the developer resources needed to complete tasks throughout the company's technical domains. These might include: UI, middleware, server, database, distribution, monitoring, and DevOps.

Thus, theory goes, this full access to the means of production guarantees quality products, on time, on budget, with an ever increasing velocity. And, for a short time this is true. With clear, focused, business objectives its easy to prioritize a team's skills and resources to achieve goals. Unfortunately, it fails for one simple reason; humans.

Mastering all the skill proficiency requirements for Full Stack is more than can be expected of any but a handful. Consider this non-inclusive list of some of the languages, libraries, and frameworks a developer would need proficiency with (not just familiarity) to be truly "Full Stack";

• CSS
• HTML
• Slime/transpilers
• Javascript
• Ajax
• JQuery/Selectors
• Bootstrap
• Underscore
• Angular/Phoenix/React/Rails
• REST
• GraphQL
• Redis
• MySql/Postgres
• Kafka/RabbitMQ
• Phoenix/Phoenix Live
• Elixir/Ruby/C#
• plus all associated test frameworks.

That's a lot to learn, but mastering something requires far more than mere proficiency with its syntax.

Like any natural human language, each software language, library, and framework has its own idioms, dialects, and phraseology that can take varying degrees of time to master. And, like natural language, lacking that fluency usually produces poor, and sometimes disastrous end results. Also, software languages, tools, frameworks, and paradigms evolve rapidly, requiring constant attention to maintain fluency.

But wait, it gets worse

Each domain of a product's technical stack has considerations beyond the language chosen to implement it. For instance, adding a column to a database is a simple thing. But the consequences of doing it in the wrong place can have large impacts on your business that are difficult to unravel. Additionally, proper testing techniques for all those languages can vary substantially and doing it wrong can hide failures, and even hamstring new features in production code.

Granted, some of these negatives can be countered with skill sharing and consistent, high quality code reviews. But again, this kind of diligence is difficult to achieve in the long term when deadlines rear their ugly heads.

According to LinkedIn, the turnover rate for software developers is the highest of any sector at over 13%. How much knowledge sharing, code consistency, architectural direction, and quality will be quantitatively passed along when average tenure for all but the highest paying companies is about 2 years?

You mean we gotta pay them too?

It probably goes without saying, but with the greater number of fluency requirements, the harder it will be to find and evaluate qualified employees. Correspondingly, their pay expectations will be higher, and the more likely they'll be hired away.

That's bad, what do you propose?

Domain (horizontal) alignment

Generally speaking horizontal development is organized around domain competencies, and the extended experience needed to make wise decisions for the long term health of the code base.

UI, for instance, needs language skills specific to their target devices (desktop, iOS, Android), and browsers. This domain also requires a unique set of experience-based skills on how to make the customer interface responsive, reliable, and efficient. Due to all the devices and browsers, potential corner cases are plentiful and only experience can avoid them. Given that your UI is usually the first contact your customer has with your product, the need for experience in this domain is obvious.

"Platform" or "server side" code has similar domain specific concerns. Mistakes here are easy to make, expensive to fix, and can have a deep and potentially fatal effect on the product. Experience in this domain helps companies anticipate and design for concurrency demands, response times, memory requirements, reliability, architectural separation, and scaling.

Benefits of domain alignment

Given this, there are several benefits horizontally aligned organizations have over those that are vertically aligned. Generally these benefits are due to reduced breadth of proficiency requirements, increased depth in those proficiencies, and more applied long-term experience. Some examples:

• Easier to find (and evaluate) qualified, like-minded employees.
• Greater focus on domain concerns, yields higher quality of code
• Higher code quality enables increased velocity and improved customer value and reliability
• Better appreciation of domain specific architectural issues decreases likelihood of introducing costly design flaws.

One subtle benefit that shouldn't be overlooked is the human component. While Full Stack development frequently suffers from Tragedy of the Commons, the more localized code base of horizontal organizations benefit from pride of ownership.

Simply put, it's much easier to fully understand your domain and become beneficially invested to make "your" code base better.

So why isn't everybody horizontally aligned?

Using traditional business processes, it can be difficult to predictably provide customer value when you have to drive requirements down through all those layers. Each layer has its own domain-specific concerns, deadlines, and delivery requirements. This is usually complicated by conflicting priorities and schedules of internal customers.

So, how do you get the predictable delivery benefits of Full Stack and the performance, reliability, and long-term velocity benefits of horizontal?

You need Feature Guides of course

Create a development-focused role mirroring the Product Manager's Business focus. This person needs to work closely with the Product Manager to understand the business needs, assist them in clarifying missing technical aspects, work with domain-teams to identify any long or short term impacts on architecture, ensure any needed preliminary designs or prototypes are created, solicit input on broad-based implementation strategies and any architectural changes, coordinate with domain teams to appropriately prioritize work within their schedules, and finally track the progress, quality and completeness of the required work.

In some organizations these responsibilities might fall to the Development Manager, but personal experience shows much greater benefit for the organization if it's delegated to the developers themselves. Such as:

• The Human element of "owning" features is a powerful motivator
• Identifies developers ready for more responsibility
• Provides a "safer" way for developers to "try their hand" in different domains and languages they might have interest in
• Opportunity to groom and assess likely leadership candidates; which are always in short supply
• Builds a more thorough understanding of the overall architecture
• Cross-team coordination improves ties within the whole development organization
• Attributable ownership leads to greater opportunity for recognition and improved morale
• Project success rates provide more quantifiable metrics for performance evaluation
• Greater breadth of interactions improves the quality of peer reviews

It should be obvious that the seniority of the Feature Guide would be relative to the breadth and corporate impact of the feature. The Guide's primary responsibility is not necessarily do all (if any) of the work themselves but rather to coordinate and facilitate the technical details of predictably releasing high quality customer value.

Nothing is black and white

When a company or product is in its infancy, the smaller teams, reduced domain responsibilities, and need for an immediate marketable product (whatever the cost), then Full Stack can provide that focus.

However, the when the company first feels the unwieldy nature of all the accumulated tech debt and talks begin of the first re-write, they should switch to Horizontal and Feature Guides or it's likely the "new thing" is going to look just like the "old thing".