Understanding why certain features are not delivered can often be challenging. Management might blame the technical teams, while the technical teams point fingers back at management. Meanwhile, the business side is caught in the middle, trying to identify the root cause while pushing for results regardless of the circumstances. This scenario typically arises after significant company growth or when earlier issues, previously easy to fix, have been neglected over time. It’s a common misconception that all problems in a tech company are purely technical; this is far from the truth.

In this article, I will outline areas within a company’s organization that can significantly hinder feature delivery. I will also suggest directions to investigate to identify root causes, which can then be escalated or resolved within your level of authority.

It’s crucial to understand our working environment before implementing any changes or improvements. Although many insightful books have been written on this topic, not all approaches will fit every company. This is not a reflection of doing something wrong, but rather an acknowledgment of the unique nature of each company.

An important note is the insights shared here are primarily related to software development and are most applicable to companies or departments with 50 or more employees.

Organizational structure

First and foremost, understand the size and structure of your company. Identify the various departments and clarify your expectations from each. Assess whether all these departments are necessary. Create a diagram of the organizational structure, detailing each department and its roles, ensuring you understand what they do and why they exist. Often, each department consists of several teams — include these in your diagram as well but don’t describe them for now just keep team names.

As companies grow, organizational structures can become complex, making it difficult to track progress. In this complexity, you might lose sight of the original rationale behind the creation of certain departments or teams. Some teams might have been established to address problems that are no longer relevant. Here, is how it may look at a high level:

Once you have a clear diagram of your organizational structure, what comes next?

Employee hierarchy

Next, it’s essential to map out the hierarchy of your employees. Understanding who reports to whom, and why, is crucial. Line managers need to effectively communicate with their subordinates, whether they manage a large business unit or a small team. Communication should be clear, either in technical or business language, as handling both can be challenging. In larger companies, there may be direct and functional managers with distinct areas of responsibility, which should be clearly represented in your hierarchy diagram.

An employee hierarchy not only clarifies reporting lines but also helps identify verticals within the organization. Verticals are hierarchical structures that serve as shared resources across multiple departments, such as designers, HR, DevOps, and even developers. While verticals can be very beneficial, they can sometimes become bottlenecks, particularly when developers work on different projects and report to managers who are not familiar with the business goals or technical challenges. As a result, developers don’t get a proper feedbacks, managers don’t have a proper context. Therefore, understanding the hierarchy is vital for identifying and analyzing potential issues or prioritizations of the tasks. At the end, you will have something like this.

Annotation

CEO — Chief Executive Officer

CPO — Chief Product Officer

CTO — Chief Technical Officer

COO — Chief Operational Officer

HD — Head of Design

PO — Product Owner

HE — Head of Engineering

HS — Head of Sales

HM — Head of Marketing

D — Developer

PM — Product Manager

TL — Tech Lead

EM — Engineering Manager

S — Sales Manager

M — Marketer

Compare your organizational structure with your reporting lines to gain insights into the involvement of each employee in various activities. Moreover, aligning your organizational structure with the employee hierarchy can help determine whether individuals are working within the same departments and teams and towards a common goal. The template of mapping is totally up to you but it could be like this:

Team’s responsibilities

It is important to clearly define the area in which each team operates. If a team works with code, specify the services they use and those they own. Surprisingly, these can often be different. Determine if the team operates solely within one department or if it is a platform team working on core features utilized by other teams without directly altering them.

Creating a table can be very helpful, with the following columns: team name, department, list of owned services, list of general services the team can modify but does not own (ideally, there should not be such services), and a brief description. This table will help you examine if multiple teams are working on the same codebase, leading to conflicts, or if there is a lack of clarity regarding their areas of responsibility. It can also reveal if a team is primarily fixing bugs or dabbling in various tasks without a clear focus.

This level of detail is crucial for identifying overlaps, conflicts, and gaps in team responsibilities, ensuring smoother collaboration and more efficient project execution.

Employee’s responsibilities

In addition to describing teams, it is crucial to understand general employee’s positions and prepare a detailed description of their responsibilities. Often, what management envisions may differ significantly from what employees are actually doing. The software development industry has a variety of positions, and expectations can vary greatly from company to company. For instance, the role of an Engineering Manager can differ widely, not to mention roles like Delivery Managers, Data Scientists, Architects, Technical Leads, and so on. In some companies, a single person might be expected to fulfil multiple roles.

Setting clear expectations for each position is essential. This clarity not only helps track activities properly but also ensures that employees understand what is expected of them and what falls outside their scope. This applies to all positions within the organization. Clear role definitions help prevent overlap, reduce confusion, and ensure that everyone is working towards common goals in an efficient and organized manner.

Feature delivery process

By now, you should have a clear understanding of your company structure, employee hierarchy, and responsibilities. Although things might seem confusing, the goal is to first understand the current state before making any changes. Now, it’s time to describe your feature delivery process — how business features move from the initial idea to production.

Please, don’t focus here on the technical aspects like CI/CD, but on the flow from business to developers, assuming developers write code and deploy it directly to production. The aim is to identify any issues in your process from business to team and see how well employees align with it.

Consider these aspects:

• How often do you plan new features and assign work for each department and team?
• How do you set and measure key performance indicators?
• Do you use milestones? Who is involved in their initial preparation? How do you plan them with the team?
• Who coordinates the planning and execution process?
• Are you truly an agile company? Do you use frameworks like SAFe, Prince2, or PMP, or do you have something customized that works for you?
• How do you handle cross-team complex tasks and control progress? Do you have a structured approach, or do you rely that things somehow being resolved?
• 
  

Remember, each level of management and reporting adds complexity and uncertainty, regardless of the direction. Ultimately, your process diagram should answer one simple question: “How?”

You may play with the templates and adjust them to your needs. Here is a very high-level example of the delivery process without key players who regulate delivery but with timeframes.

So

If you’re unsure how to create this diagram, consider using BPMN (Business Process Model and Notation) or a simpler format like rectangles and lines to ensure clarity and understanding among all stakeholders. The key is to make the process clear and comprehensible.

Gather feedback

Once you have mapped out the company structure, employee hierarchy, teams and position responsibilities, and the delivery process, share all your findings with the organization and conduct a survey, preferably anonymous. This baseline highlights how your company operates. While you might have prepared this overview yourself or delegated some tasks, it’s likely that developers, designers, and analysts were not directly involved. Their feedback is crucial to assess the accuracy of your findings.

Ask employees to evaluate the quality of your documentation. What do they think about the delivery process? Does it truly reflect how things are done? Where do they see impediments?

Expect a variety of complaints and feedback that will help you refine your findings to better match the reality of the company’s operations. This feedback is vital as context often gets lost through multiple levels of hierarchy, and gathering input from all levels will provide a clearer, more accurate picture of the organization.

Estimate results

Now that you have a comprehensive description of how your company or departments operate, you can begin to analyze and seek potential issues. This baseline provides a clear starting point for understanding and solving problems.

Here are some areas to focus on:

• Are your departments structured? Are the reporting lines clear?
• Can line managers really provide feedback regarding their area of responsibility?
• Is there confusion or uncertainty in transforming business requirements into technical tasks?
• Are there dependencies on other teams that cause delays during development?
• Are employees involved in activities that are outside their main area of responsibility, hindering their primary tasks?
• How well does the employee hierarchy align with the team structure?
• Is the reporting hierarchy effective, or are there gaps in communication and context?
• Are different teams working on the same services, leading to conflicts and time wasted on deciding task ownership?
• Are there any teams or departments without clearly defined responsibilities or missing key players?
• Are some teams not integrated into any department?

At the end you may prepare a list of real problems your company has, that is something you will be working on. Prioritize them from critical ones which require immediate interaction to “good to have” improvements.

How to make changes

You might be wondering, “This all sounds great, but how do I actually improve things?” That’s a good question, and the honest answer depends on the specific problems you identify and your business needs. However, one crucial piece of advice is to avoid trying to change everything at once. Instead, implement small changes incrementally, evaluate the results, and iterate. Remember, the agile approach works not only in software development but can be applied to any type of organizational change.

Here are some steps to guide your improvement process:

• Ensure employees know exactly what their roles entail and what falls outside their responsibilities.
• Create well-defined departments or domains and assign specific teams to each domain.
• Define clear areas of responsibility and minimize overlaps for departments and teams.
• Consider familiarizing yourself with the Team Topologies approach, which introduces platform, stream-aligned, enabling, and complicated-subsystem teams to cover various aspects of software development.
• Review and adjust your employee hierarchy to align with the newly established domains and teams.
• Ensure reporting structures are clear and that progress tracking is straightforward.
• Choose methodology or framework you will use for feature delivery and tracking results.
• Test changes on any department, preferably not critical one and assess impact, refine your approach based on feedback and results.
• Continuously improve by applying the chosen mindset to organizational changes.

By following these steps, you can make informed, incremental changes that gradually improve your organization’s efficiency and effectiveness.

Summary

I aimed to highlight common issues that can arise in any company or department. I intentionally avoided recommending specific frameworks or approaches because each company has unique goals and structures, and it’s crucial to decide what works best for you.

Again, it’s easy to put the blame on developers, but remember, they might be unaware of business priorities or being blocked by unclear delivery processes. Sometimes, the business itself creates blockers unconsciously. I hope this article will help make the first steps towards improvement.