My Scrum Team works within the SAFe framework. I raised an issue with technical leadership for decision making when I realized I [in my role as a Scrum Developer] had no answers or ideas.

Our unit [team? project?] has a very "flat" hierarchy and there are therefore no organizational Engineering Managers, Tech Leads or other engineering leaders to make technical decisions.

My Scrum Team is one of seven teams. We raised the issue that decisions around the direction our unit takes in terms of code, code design, coding practices, coding methods, etc. are failing through the cracks causing tech debt and bad code.

In a SAFe implementation who is responsible for making significant or cross-team decisions? If it is not one person, how do we do this within SAFe?

  • 1
    I find it funny: why do you ask on "Project management" a question about how to do project management in a company where you refuse to do project management? Because "too flat organization" (like yours) and "project management" are mutually exclusive.
    – virolino
    Commented Oct 26, 2022 at 9:57
  • 4
    How can you have departments in a flat hierarchy? By definition, a department is a piece of a hierarchy.
    – virolino
    Commented Oct 26, 2022 at 9:58
  • What is your job in the company / team? Why do YOU have to provide answers?
    – virolino
    Commented Oct 26, 2022 at 9:58
  • 1
    Any team has a team leader, whether formal or informal. How can your team be without a team leader?
    – virolino
    Commented Oct 26, 2022 at 10:01
  • 2
    @user32613 I have expanded that into an answer. If those people are saying it's "not really their bag", they need to understand what their role is, because the SAFe framework says that it is. If they won't do what they are responsible and accountable for, you aren't doing SAFe. I'm not a fan of SAFe, but it does give you the tools needed to solve this problem. The people are just ignoring that.
    – Thomas Owens
    Commented Oct 26, 2022 at 12:43

3 Answers 3


NB: The original question was updated to reflect the Scrum-like and SAFe elements of the OP's environment, and shift the focus from "hierarchy" to decision-making within the different layers/roles within SAFe.


Within each Agile Team—they're functionally Scrum Teams, but are not really allowed to be called that because they deviate in some ways from formal Scrum—whether within a scaled framework like SAFe, Nexus, or something else, architectural and engineering decisions are team-level decisions that the Agile Team agrees upon collaboratively between the Product Owner, Scrum Master, and Develoeprs on the team. However, decisions that are cross-team and may impact the the whole Agile Release Train are the responsibility of one or more roles based on the specific SAFe Configuration in use.

When in doubt, ask the Release Train Engineer (RTE) for guidance. It's explicitly listed in their job description to shepherd the ART through the release train process, facilitate synchronization, and help resolve impediments. They can't help you with things they don't know are going on, though, so make sure your team is keeping the lines of communication open with the RTE!

Analysis and Recommendations

Team-Level Decisions

Since you haven't defined the scope or context of your specific issues, if they are team-level decisions then it is the Scrum Team's responsibility to align their architectural and engineering decisions with the rest of the organization during PI Planning. PI Planning is where the whole release train defines what the Program Increment should deliver through PI Objectives, and then each team builds its own plan on a Team Backlog on how they will deliver their own increments via Team PI Objectives and the team's own Definition of Done so their work can be properly integrated into the Program Increment.

In short, it is entirely up to each Scrum Team to define how they will do the work that aligns with the rest of the Agile Release Train. As long as the deliverable can be aligned with the rest of the work being done for the PI, no one outside the team really needs to be consulted.

Train-Level Decisions

This is where the answer is "it depends." Depending on your version and level of SAFe, there are multiple roles responsible for ensuring that the work done by each Scrum Team can be integrated into a cohesive Program Increment. These sorts of questions are generally addressed during PI Planning, but if they arise during the course of the PI then the Release Train Engineer is the person who can direct you to the appropriate resource within the Agile Release Train (ART) for answers.

However, as a general rule, there's nothing stopping teams from collaborating with one another. Agility is founded on communications and collaboration, after all!

If your work depends on another team's input or output, that should have been captured during PI Planning. If not, then talk to the other team to see how you can work together. This may be as simple as two Scrum Masters informing one another of unexpected dependencies, or as complex as setting up a meeting between one or more teams to coordinate work.

Of course, if the problem is big enough, the Product Owner and/or Scrum Master should be involving others within the Agile Release Train to resolve the concerns. That will certainly involve the Release Train Engineer, and may involve other roles as well.

"Enforcement" Isn't a Thing; Agile Teams are Self-Managing

In any truly agile framework, there's no "enforcement" in the typical command-and-control sense. Agility is based on collaboration and working agreements, and teams and release trains self-managing to the working agreements or collectively changing them when necessary. The whole Agile Release Train is involved in collaboratively defining a Definition of Done (DoD) for the ART and each PI, and individual teams are also able to define their own DoDs so long as they are aligned with the ART.

That doesn't mean there can't be standards, though. Some are agreed-upon Definitions of Done across the ART, while others are provided by the Solution Train in versions of SAFe that have more than one ART. System Teams and Shared Services teams (if present) may also collaborate or provide standards across an ART or Solution Train as part of the Architectural Runway required to deliver the PI Objectives, increments, or other enablers.

Again, if you're using SAFe at that level of complexity, involve your Release Train Engineer, who may then involve the Solution Train Engineer (STE) or other roles if needed. Anything above the team level really ought to involve the Release Train Engineer for your team's ART; that person may not have the answers, but the RTE is the right person to point you in the correct direction, or to raise systemic implementation problems like a lack of role ownership with the correct people.


Working agreements and collaborations that aren't effective should be brought up during the Scrum Team's Iteration Retrospective (if not blocking the work) or immediately to the RTE if it is blocking.

There are also inspect-and-adapt opportunities within the Post-PI Planning Retrospectives and Innovation and Planning Iterations. The first is a baked-in event for all levels of SAFe, and the Iteration Retrospective should be baked into all Agile Team planning. Non-standard or urgent inspect-and-adapt concerns should be raised to the RTE immediately by the Agile Team (usually through the Scrum Master), but definitely not left to linger if the concern would block the team's planned deliverables for the Program Increment.

See Also


If you are using the SAFe framework, your System Architect, Solution Architect, and/or Enterprise Architect need to step up. Each of these roles is responsible and accountable for "defining and communicating a shared technical and architectural vision" and to help ensure fitness for intended use and purpose. All SAFe implementations have a System Architect since this role is part of Essential SAFe. You may have a Solution Architect or Enterprise Architect if you are using SAFe in the Large Solution or Portfolio configurations.

The SAFe Scrum Master, Release Train Engineer, and Solution Train Engineer can also play a role here. The people with these roles handle ensuring that the people across the organization have the knowledge and skills that they need to do their jobs effectively, help the teams in delivering value, escalating any impediments to the right people, and driving continuous improvement within various parts of the organization.

None of the SAFe roles - the Architects or the Train Engineers - need to form a hierarchy. Although some organizations do implement it this way, SAFe does not require a formal hierarchy where the Enterprise Architect is above the Solution Architect(s) is above the System Architect(s) or where the Solution Train Engineer is above the Release Train Engineer(s) is above the team's SAFe Scrum Master. Regardless of your hierarchy (or lack thereof), there are still responsibilities and accountabilities associated with these roles.

Depending on your SAFe configuration, I would be looking toward your System Architect and RTE (in the Essential configuration) or the Solution Architect and STE (in the Large Solution configuration) to be taking the lead on the technical practices that extend across teams. Since you are building a cohesive product, there are key practices that, if not uniform across teams, can slow the development down. Minimum standards need to be agreed upon and set at the product (solution) level. Other decisions, including making the standards stricter, can be pushed down to individual teams and lessons learned can bubble up and out.


If there is nobody at designated to make decisions, then the team should reach a decision on how to proceed. Someone with higher rank must approve the decision, I guess, to avoid other problems.

So the decisions might be made by:

  1. Whoever is around with higher rank
  2. A trusted and experienced team member
  3. 50% + 1 majority
  4. 75% majority
  5. 100% majority (unanimous)

and jokingly:

  1. coin flipping
  2. rock, paper, scissors
  3. cards game (poker or any other)
  4. normal roulette
  5. Russian roulette


A perfectly flat organizations cannot exist, unless there is only one person. If there are 7 teams, someone made that decision. Or agreed to that proposal. Someone is paying the salaries. Etc. So from this POV, there really is at least one person in the company with "higher rank".

As a minimum, they have to decide who will make the decisions.

  • 1
    Majority of team members on >5 teams is significant effort. That's more than 30 people who need to be involved. Commented Oct 26, 2022 at 9:26
  • I would really hesitate proposing a "majority" of 2.17% :D And I really made an effort to abstain from commenting that the science of project management appeared for a very good reason. There are many other comments that I can make around the subject, but they do not answer the question in the way it was asked.
    – virolino
    Commented Oct 26, 2022 at 9:31
  • BTW, how do you know the details about the team size? :D You have a different user ID than OP, and there are no other comments.
    – virolino
    Commented Oct 26, 2022 at 9:32
  • I don't, I just assumed an average of at least 5-6. Notice the number of teams on the comment is different as well. I was more making a general point about the issue of scaling involvement in decision-making without some form of delegation, whether that is upwards or downwards. Commented Oct 26, 2022 at 9:41
  • Oh, gosh! I totally misread the ">5 teams". Sorry. Yeah, now it makes sense.
    – virolino
    Commented Oct 26, 2022 at 9:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.