Between Relationships and Rules: How to Get Things Done in Imperfect Organizations

You may have encountered projects like this: goals are set, plans are meticulously written, everyone is working, yet the project suddenly grinds to a halt. For example:

• A government department is promoting cross-departmental data sharing. Data providers are willing to cooperate, and users have clear needs, but data permissions, privacy assessments, project budgets, and accountability for results are held by different units. Each department is fulfilling its statutory duties, but the project has to wait for them to reach a new agreement before it can proceed.
• A university is building a unified research management platform. The central technical team is responsible for the system, departments control actual processes, and research and finance departments set management rules. The project lead can organize meetings and update plans, but cannot unilaterally change business processes or demand that departments allocate personnel. A pilot has already started, but the system could still stall due to fragmented decision-making.
• A retail enterprise is developing a demand forecasting platform. A pilot model has been completed, but the product owner left during an organizational restructuring. The new owner can manage the product backlog but cannot represent the replenishment department in accepting inventory risks; key engineering resources have also been reassigned to other projects. The model can still be optimized, but no one can clearly state who decides the launch scope or who provides production resources.

These three scenarios are not complete reproductions of any single organization, but rather recurring composite situations in cross-departmental projects. Organizations have not lost their institutional frameworks, but the decision chain for specific projects can be broken due to personnel changes, divided responsibilities, and resource shifts.

If you are an engineer, continued technical optimization may not be useful; if you are a project lead, simply holding more meetings may not solve the problem. You need to find the people who genuinely have the authority to make trade-offs, while avoiding taking on an unbounded responsibility for the organization.

So, how can you leverage the support of specific individuals to get things started, and how can you protect yourself with clear boundaries? This starts with understanding the organization’s actual decision chain.

I. Organizations Have Systems, So Why Do Projects Still Get Stuck? #

An organizational chart tells people who holds what position, but it doesn’t necessarily explain who can adjust scope, who controls key resources, who can coordinate different departments, or who has the authority to decide how much risk the organization will take in a specific task.

In “Personal Allegiance and Role Responsibility: From Pre-Modern to Modern Management”, I discussed how pre-modern management relied more on loyalty to specific individuals, while modern management attempts to embed responsibility into roles, processes, and transferable systems. Real-world organizations often contain both mechanisms simultaneously. Sociologist Mark Granovetter points out that economic action is embedded in specific social networks [1]. Formal institutions do not make relationships disappear; their more important role is to reduce the reliance of cooperation on private relationships.

What truly fails in many cross-departmental projects is not the institutional framework itself, but the interfaces between institutions.

After personnel adjustments or tasks cross departmental boundaries, responsibility, authority, and coordination ability do not re-form into a complete decision chain. Each department continues to operate according to its own rules, but the cross-departmental task loses the person capable of making overall trade-offs.

At this point, a project lead cannot just look at how many meetings have been held or how complete the plan is; they must also assess several more practical questions: Can bad news reach the people who truly have the authority to decide? Can the scope, resources, and risk ownership be stably recorded? When conflicts arise between departments, who ultimately makes the trade-offs?

Sociocultural factors also influence how organizations fill these institutional gaps. Some environments are more accustomed to awaiting directives from superiors, relying on personal connections for coordination, or avoiding public conflict; others emphasize contracts, roles, and professional judgment. Cross-cultural leadership research shows that different societies have different expectations regarding power distance and ideal leadership styles [2]. However, culture can help people understand why organizational members react in certain ways, but it cannot rationalize ambiguous responsibility and a lack of authorization.

Business managers can adjust budgets and personnel within their authority; government projects are constrained by laws, budgets, and administrative procedures; schools must also consider academic autonomy, professional judgment, and campus governance. The support of specific individuals cannot replace these institutional frameworks, nor can it make unauthorized decisions legitimate. The true value of such support lies in helping the project find the authorized decision-makers and bridging temporarily broken collaboration interfaces.

Finding the true decision chain only means that things might continue to move forward. The implementer must also determine: Is this problem, for which no one is responsible, an opportunity, or is the organization trying to offload risk downwards?

II. Are All Unowned Problems Worth Taking On? #

Not necessarily.

A problem without a clear owner can allow someone to build influence, but it can also be a way for the organization to offload risk downwards. The key determinant is not whether people often complain, but whether the problem genuinely limits the output of the entire system.

A difficult-to-use report interface might dissatisfy many people, but it might not affect the final outcome. A data standard that remains unconfirmed for a long time might seem minor, but it could deprive model training, experimental analysis, and performance evaluation of a common foundation. Solving the latter type of problem is not just completing a task; it allows many people’s subsequent work to proceed smoothly.

However, “unowned” problems come in at least two types.

One spans multiple departments, and the organization genuinely wants to solve it but lacks a coordinator. The other has no budget, no authorization, no stable support, and the organization is unwilling to admit that existing conditions are insufficient. The former might be an opportunity; the latter often means the organization needs someone to take responsibility for a systemic gap.

Before taking on a task, you need to clarify a few key things: whether the organization genuinely wants to solve this problem, who defines results and handles acceptance, which departments must cooperate, and who resolves resource and priority conflicts. More importantly, when prerequisites change, who has the authority to pause the task, reduce scope, or renegotiate commitments.

There is also a more sensitive question: If the project fails, will the organization re-examine the prerequisites and past decisions, or will it simply look for someone to bear the blame?

These questions often reveal more about whether an opportunity is real than job titles do.

A task is more likely to be a genuine opportunity only if it simultaneously comes with commensurate responsibility, authority, and resources. If the organization only delegates responsibility without providing the necessary authority and resources, be wary that risk is being offloaded downwards.

Even if the organization is willing to provide support, the implementer still faces a more sensitive question: Whose help can be leveraged, and how much responsibility should be assumed for that support?

III. You Can Leverage Leadership, But How Much Responsibility Should You Take? #

Complex work often requires a capable Project Sponsor. This person might be a senior executive, a government official, a project committee member, or a university or departmental head. They can confirm priorities, coordinate resources, and facilitate necessary trade-offs when the project encounters cross-departmental conflicts.

Completely rejecting such personalized support might prevent the project from starting; but gaining someone’s support doesn’t mean you must become “their person.”

To describe the state between these two, this article provisionally calls it “limited allegiance”: leveraging a specific individual’s trust and power to complete a task within defined boundaries, without pledging personal loyalty or abandoning professional and institutional boundaries. What an individual borrows is the support needed to complete the task, rather than binding their personal identity and long-term future to any single person.

When accepting a task, you can sequentially confirm several questions:

1. Define results: What problem does the project solve, and who accepts the results?
2. Clarify dependencies: What data, systems, and departments are needed for cooperation?
3. Confirm authority and responsibility: What can you decide, who provides resources, and who accepts the outcome risks?
4. Commit to progress: Provide a reliable timetable after preconditions are met.

In the scenarios mentioned at the beginning, a qualified project sponsor does not need to take over daily work. What they truly need to do is confirm the project scope, coordinate necessary resources, clarify who accepts business risks, and provide an escalation path for cross-departmental conflicts. The project lead translates these decisions into action, while professionals assess the technical and professional reliability of the solution.

Project leads cannot create authority by virtue of their position, nor should professionals accept organizational risks on behalf of business departments or management.

Job titles themselves do not automatically confer the power needed to complete tasks. If a person is responsible for delivery but cannot influence scope and priorities, has no authority to coordinate resources, and cannot escalate conflicts to the true decision-makers, then individual departments will continue to retain their decision-making power, and cross-departmental failures may converge on this one person.

Verbal support, therefore, needs to be converted into organizational commitment. Meeting minutes, decision logs, and written confirmations are more important for ensuring the team has a common understanding of scope, dependencies, and risks, and for preserving context for later adjustments and handovers. This way, even if time, personnel, and interests change, the project does not have to repeatedly argue about what decisions were made originally.

Whether authorization is reliable can also be seen in how the supporter treats bad news. Amy Edmondson’s study of 51 work teams in a manufacturing company found that team psychological safety is related to learning behavior [3]. While this study cannot directly prove that all organizations will show the same results, it highlights an important mechanism: if members fear that raising problems will lead to interpersonal punishment, the team will find it harder to detect and correct errors in a timely manner.

If a supporter demands loyalty but consistently fails to clarify authority; or on one hand demands the team bears results, while on the other punishes those who report risks, such support is closer to risk transference than to bounded authorization.

Therefore, relationships can help a project gain authorization, records can solidify it, and results verify whether that authorization is truly effective.

With these boundaries, the implementer has the conditions to move work forward. But knowledge-based projects have another layer of difficulty: the task itself is often unclear. The technical personnel then need to figure out how to turn a vague request into a decision the organization can actually make.

IV. How Can Technical Personnel Turn Vague Requests into Decidable Problems? #

Many knowledge-based tasks are not clearly defined at the outset.

The requesting party might say, “build a model to increase conversion rate,” “integrate this data,” or “establish a cross-departmental platform,” without specifying who defines metrics, who provides conditions, who uses the results, and who bears the cost of errors.

If the implementer directly turns these requests into a schedule, they will prematurely commit to results without a decision-making boundary.

Facing a request like “make predictions more accurate,” technical personnel can avoid discussing models and launch dates initially, and instead ask some more fundamental questions: What decisions will more accurate predictions support? How will stores use the results? What costs will overestimation and underestimation incur, respectively? Who has the authority to accept these errors?

Once these questions are answered, model metrics begin to have organizational meaning.

Technical personnel then need to clearly separate confirmed facts, still-to-be-verified assumptions, and the model’s applicability boundaries. If multiple solutions exist, they should detail the resources required, potential impacts, and unavoidable risks for each, then ask those with true authority to make the trade-offs.

Doing this is not about pushing technical problems onto management; it is about clarifying the inherent trade-offs in technical choices and then handing decisions beyond professional authority to those who truly have the power to make them.

Data and AI projects especially require such clear boundaries. Technical teams can design metrics, compare alternatives, and select thresholds, and they must be accountable for implementation quality, data processing, and known technical risks. But possessing technical expertise does not grant a team the default right to dictate business priorities, compliance boundaries, or risk allocation. Technical professionals can design solutions, but they cannot decide for the organization who bears the consequences. The Association for Computing Machinery (ACM) Code of Ethics and Professional Conduct requires practitioners to honestly explain system capabilities, limitations, and potential problems [4]; the National Institute of Standards and Technology (NIST) Artificial Intelligence Risk Management Framework also emphasizes governance, distinct roles, and accountability throughout the AI lifecycle [5].

Those new to the workforce do not need to immediately understand the entire power network, nor do they need to deliberately cultivate “connections.” A more practical starting point is to clarify requirements, write down assumptions, report risks promptly, and only commit to results they are capable of delivering.

The organizational credit a person initially builds is usually not because they “worked on a big project,” but because colleagues gradually confirm: this person provides reliable information, does not hide problems, and delivers clear results on promised tasks.

However, completing a project is only the beginning of building credit. After the project ends, how the organization explains its success determines whether this credit remains attached to a specific relationship or gradually belongs to you personally.

V. After Something Is Achieved, What Does the Organization Remember? #

After a project is completed, the organization might form two entirely different understandings:

“This person knows a certain leader, so they can mobilize resources.”

Or:

“This person can identify problems, organize collaboration, expose risks promptly, and deliver verifiable results.”

The former relies on private relationships. If the supporter leaves, personal influence might disappear with them. The latter is closer to transferable organizational credit: even if teams, projects, or leaders change, others are still willing to trust this person’s judgment and commitments.

This credit cannot solely be told by the individual; it needs verifiable evidence from third parties.

Decision records explain what problem the project solved, why a certain scope was chosen, and who accepted which risks; deliverables explain which metrics improved, whether conclusions can be replicated, and what insights failures brought; collaboration records explain who contributed, whether risks were exposed promptly, and how the team handled problems.

These records will also slowly change the organizational memory. What others remember is no longer just “who you know,” but how you assess problems, organize collaboration, and deliver on commitments. Simultaneously, requirement records, decision logs, and post-mortems will provide a better starting point for the next similar undertaking.

Project leads should ensure participants receive recognition commensurate with their contributions and should proactively take responsibility for explanations when issues arise. However, explanatory responsibility does not mean absorbing all systemic responsibility. If failure stems from insufficient authorization, lack of resources, or decisions made at a higher level, the project lead should not use “accountability” to obscure the true reasons.

In organizations like government and schools, the allocation of budgets, opportunities, and benefits must also adhere to public procedures and conflict of interest rules. Personal relationships can aid communication but cannot justify the private disposal of public resources.

Organizational credit makes others willing to entrust tasks to you again. But if every success only deepens the organization’s personal dependence on you, that credit has not yet been truly converted into organizational capability.

VI. When You Are Not Present, Can Things Still Continue? #

“The organization can’t do without me” can provide position and negotiating leverage in the short term, but it can also slowly lock a person into their original role.

If all problems come to the same person, and the team cannot make independent judgments, the organization both relies on them and fears that key resources are controlled by them. Being indispensable can be a stage in building credit, but it is not suitable as a final goal.

A more mature approach is to transform personally accumulated resources into reusable organizational capabilities.

A project lead can turn private external contacts into stable interfaces, experience into verifiable methods, and temporary coordination into clear decision and escalation paths. For data and AI teams, version control, automated testing, data lineage, runbooks, and handover documentation are all concrete ways to embed individual knowledge into systems.

For a project lead, true success is not that all future projects must be coordinated by them, but that the team gradually becomes capable of independently handling recurring dependencies, decisions, and risks.

To assess whether a success has truly improved the organization, you can ask a few simple questions:

Can the results be verified by others?
Can the methods be reused by others?
When you are not present, can things continue to operate?
The next time a similar problem arises, does the organization have a better starting point than last time?

If most of these questions receive negative answers, then being “indispensable” likely just means that critical information is still centralized with one individual. If every project requires the same leader to re-approve and the same person to re-coordinate, the organization has not truly accumulated capability.

Even if a person breaks free from dependence on a superior, they might be building a new structure that demands colleagues and subordinates depend on them.

Not all organizations welcome this transformation. Some leaders are willing to explicitly authorize, keep records, and turn effective practices into team mechanisms; other leaders need a “go-to person” who is always available.

Therefore, when evaluating whether an organization is worth long-term investment, you cannot just look at how many opportunities it gives an individual. You can also observe: After each success, do roles become clearer, do rules become more stable, and do others gain the ability to act independently?

If repeated successes only lead to deeper personal ties, then sometimes leaving is more rational than continuing to prove yourself.

Summary: Relationships Can Only Be a Starting Point #

In imperfect organizations, people cannot wait until all systems are perfect before acting. The support of specific individuals can sometimes bridge temporarily broken decision chains, allowing cross-departmental work to restart.

But such support is only worth accepting when boundaries are clear. Implementers need to first define results and dependencies, then confirm authority, resources, and risk ownership, and only then commit to progress. Once work begins, use records to solidify authorization, report risks truthfully, build credit through results, and then distill a single success into a capability that others can verify, reuse, and take over.

For those new to an organization, patience is not passive waiting, but first observing how things actually happen. There’s no need to rush to prove yourself by taking on all problems, nor should you interpret all collaboration as a power game due to one or two setbacks. First, observe what different roles truly care about, which commitments are ultimately honored, and how the organization treats those who make mistakes or raise objections, then decide how much you are willing to invest.

For experienced professionals and those in engineering or management, the true value of experience is not just finding solutions faster, but knowing which shortcuts, though effective in the short term, will erode long-term credit. “This is how we’ve always done it” explains why certain practices persist, but it cannot justify concealing issues, distorting data, bypassing professional judgment, or shifting responsibility onto newcomers.

The more chaotic the situation, the more important it is to clarify what is known and unknown, respect facts, and respect colleagues’ professional judgment and integrity. These practices may not make things faster immediately, but they determine what kind of professional credit a person will ultimately leave behind.

Relationships can start things, but they should not be the ultimate basis for responsibility. What is truly worth accumulating is an organizational capability that can operate independently of specific individuals, not one person’s private dependence on another.

Appendix: Why Are Authority and Responsibility More Prone to Misalignment in Cross-Functional Teams? #

Tech companies often organize different roles needed to achieve a business goal into cross-functional teams. Some companies call these teams Squads. Data and AI teams might include the following members, but role combinations and naming conventions vary across companies:

A Pillar Tech Lead may oversee the technical direction and engineering standards for multiple squads; cross-squad Subject Matter Experts (SMEs) provide security, privacy, platform, or business support as needed. Architects and other experts may either belong to a single squad long-term or support multiple squads simultaneously.

Spotify in 2012 published an article that promoted the spread of terms like Squad, Tribe, Chapter, and Guild. However, Spotify did not invent cross-functional teams. The original text also explicitly stated that this was merely a “snapshot” of how Spotify worked at the time, not a finished, ready-to-copy standard model [6].

The history of matrix organizations dates back even further. With the development of large, complex engineering and project management, organizations increasingly needed to maintain both project goals and professional functions as two dimensions of management: the project line focuses on goals, progress, and overall integration, while the functional line is responsible for professional capabilities, personnel development, and engineering standards [7].

Cross-functional teams do not necessarily adopt matrix management. An organization has more typical matrix characteristics only when members are simultaneously influenced by the authority and responsibility of both the project line and the functional line.

Governments and schools may not use names like Squad or Chapter, but similar structures can still exist. Special working groups, project offices, or interdisciplinary teams are responsible for completing a specific task, while members’ appointments, professional standards, and long-term development remain the responsibility of their original department or faculty.

What is truly important is never which set of names to copy, but to clarify: What does each task line and functional line decide, and who arbitrates when conflicts arise between them?

References #

[1] Granovetter, M. “Economic Action and Social Structure: The Problem of Embeddedness.” American Journal of Sociology, 91(3), 1985, pp. 481–510. https://doi.org/10.1086/228311

[2] House, R. J., Hanges, P. J., Javidan, M., Dorfman, P. W., and Gupta, V., eds. Culture, Leadership, and Organizations: The GLOBE Study of 62 Societies. Sage Publications, 2004.

[3] Edmondson, A. “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly, 44(2), 1999, pp. 350–383. https://doi.org/10.2307/2666999

[4] Association for Computing Machinery. “ACM Code of Ethics and Professional Conduct.” 2018. https://www.acm.org/code-of-ethics

[5] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. https://doi.org/10.6028/NIST.AI.100-1

[6] Kniberg, H., and Ivarsson, A. Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. 2012. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

[7] Stuckenbruck, L. C. “The Matrix Organization.” Project Management Quarterly, 10(3), 1979, pp. 21–33. https://www.pmi.org/learning/library/matrix-organization-structure-reason-evolution-1837