One Methodology, Every Level: What a Baseball S&C Operation Looks Like Built on FYTT
Every professional baseball organization already has more data than it can act on. Force plates in the weight room, GPS units on the field, velocity tracking in the bullpen, wellness check-ins on a phone before anyone gets to the facility. The collection problem was solved years ago.
The harder problem sits one level up. A coordinator of performance owns a methodology that has to hold at the complex, at every affiliate, and at the big league level, and that methodology usually lives in his head, a shared drive, and a document that gets a little more out of date every month. It travels down the system through onboarding conversations and hope. By the time it reaches a High-A coach running a full roster by himself, what survives is the general idea rather than the actual decision rules, which means two athletes with identical testing profiles at two levels of the same organization can end up on completely different training weeks for no defensible reason.
That is a systems problem, not a coaching problem. Solving it requires the data layer and the programming layer to be the same layer, so the rules a coordinator writes once are the rules that execute everywhere. Here is what that looks like built out across a baseball organization.
Start with the groups the organization actually needs
A baseball roster does not train as one unit, so it should not be grouped as one either. Before any data comes in, a program built on FYTT starts by defining the groups the rest of the system will run on, because in FYTT a group is not a label on a list of names, it is a container that carries its own program.
The first layer is competitive role, since a starter, a reliever, and an everyday position player carry completely different demands across a week. Starting Rotation, Bullpen, and Position Players each warrant their own baselines and their own training structure. The second layer is training bias, which reflects what an athlete needs to improve rather than where he stands on the field, so a staff can build Strength-Bias, Velocity-Bias, and Balanced groups and assign athletes based on assessment rather than position. The third layer is status, and these groups are never permanent: Monitor, for athletes whose testing numbers have moved outside their normal range, and Load Management, for athletes carrying more volume than their norm.
Because an athlete can belong to more than one group at a time, none of this forces a staff to pick a single identity for a player. A starting pitcher can sit in Starting Rotation and Balanced and, for one particular week, Monitor, and each of those groups carries its own programming. That is what makes the upfront architecture worth the time, because moving an athlete into a group is not relabeling him, it is putting him on a different plan.
This is also the first place organizational consistency becomes real rather than aspirational. When the coordinator defines the group structure once, every level inherits the same containers, which means Strength-Bias means the same thing in Single-A that it means in Triple-A. An affiliate coach is not interpreting a philosophy document, he is working inside a structure that already encodes it, which is how a program deploys consistent methodology across teams without rebuilding it every season, and how group-based variants deliver real individualization without duplicate work.
Groups get built directly from the roster, and the logic behind each group is entirely yours to define
Build the Metrics Hub so every number behaves the same way
Once the groups exist, the next step is building out the data that will drive them. Some of that data is first-party and entered directly by the staff, including 1RMs, sprint times, session RPE, and a daily wellness check-in score. Some of it arrives from the technology the organization already owns, including force-plate testing, countermovement jump height, reactive strength index, isometric strength, and GPS output like total distance, high-speed running, and sprint counts.
What matters is what happens after the number lands. Once a value is in the Metrics Hub, it does not matter whether a coach typed it in or a force plate synced it in. A reactive strength index reading and a squat max a coach entered by hand are the same kind of object to the platform, which means both are comparable, chartable, usable inside a custom formula and trend view, and usable as a trigger. That is the working definition of a metrics hub. It is not a dashboard that displays a few systems side by side, it is one data layer where testing data and training data behave identically.
Deciding which tests actually earn their place in a testing battery is its own conversation, but once that decision is made, two capabilities make the data layer useful rather than just tidy. Custom formulas let a staff define the metrics their methodology actually depends on instead of the ones a vendor decided to ship, so an organization with its own composite readiness score or its own asymmetry threshold can build it and then treat it like any other number in the system. Percentile tracking then scores every measurement against the organization's own most recent thousand measurements, which means a Double-A infielder's jump height is evaluated against the population the staff actually coaches rather than a generic reference table built on someone else's athletes.
Every piece of performance data you capture, in one place, reporting itself to the right people.
Automations turn the hub into logic that runs at every level
FYTT's Automations feature handles decision-tree routing at scale, and it is a full tree rather than a single if-then rule. A trigger starts the sequence, whether that is new data arriving, a scheduled interval, or an athlete joining a team. A decision node routes down whichever branch matches first, and an action node executes at the end of that branch. A single FYTT Automation can chain several actions or branch into further decisions, and conditions combine with AND/OR logic, so a route can require more than one thing to be true before it fires.
Here is what that looks like once the groups and the hub are both in place. Say the staff tests reactive strength index on force plates every two weeks. An Automation evaluates each new result, and when RSI drops more than ten percent below an athlete's rolling baseline, it adds him to Monitor and removes him from his current training-bias group. Monitor carries its own program with reduced volume and additional recovery work, so the change in group membership is the change in training. When his next test comes back inside his normal range, the same logic runs in reverse and he returns to his standard program without anyone having to remember to check.
GPS data drives the same pattern from the other direction. A condition checks high-speed running distance against a rolling weekly threshold, and when a pitcher or an everyday position player exceeds it, the Automation moves him into Load Management, where the program backs off total volume for several days. Practitioners from MLB and Division I have talked through how to set those thresholds so they serve the game model rather than override it. First-party data works exactly the same way, since a wellness check-in score below a set threshold can route an athlete into a lower-intensity training day for that session alone. No force plate or GPS unit is required for that one, because the decision tree does not care where a number came from.
The join-team trigger handles the case where there is no data yet, which in professional baseball happens constantly. A drafted player reports to the complex, a signee arrives from the international market, a player comes over midseason, and in every one of those situations the staff is starting from nothing. An Automation triggered on joining a team can place him into an intake group that carries a baseline testing protocol and a general preparation program, so his first week is structured before anyone has entered a single number. Once his testing results land in the Metrics Hub, the same routing logic that governs everyone else picks him up and moves him into the appropriate training-bias group. The intake standard is identical whether he reports to the complex or to Triple-A, because it is one Automation rather than six coaches' judgment calls. Brad Lawson has walked through what this looks like inside a professional baseball organization running hundreds of athletes across affiliates.
None of these routes required a staff to rewrite a single athlete's program by hand. The coordinator built the logic once, based on what the organization's own experience and thresholds said mattered, and it applies itself every time new data says it should. An organization running hundreds of players through camp no longer has to choose between testing everyone and actually acting on what the testing shows.
Let the system route athletes into the right training based on their most recent data.
Keeping design, execution, and the medical record connected
Consistent logic only matters if the execution layer holds up underneath it, which is where most systems quietly break down.
Periodized plans that adapt across a season run across one timeline of any length with mixed participants assigned along it, so a staff can lay out the ramp through spring training, the in-season maintenance structure, and the stretch run in a single view. When a program drops onto the plan, the calendar updates downstream, which means a change made at the plan level does not require anyone to reconcile six weeks of workouts by hand.
Workout instances on the calendar stay editable independently of the program template, so when a coach adjusts a set on the floor, the platform tracks the variance and highlights prescribed against actual rather than quietly overwriting the intent. That distinction matters organizationally, because a coordinator reviewing a level can see not just what was written but where and how often reality departed from it, which is usually the most honest signal about whether a program is fitting the environment. Whiteboard mode runs the session in a spreadsheet view that updates in real time from athlete devices and casts to a TV in the weight room, so what the staff designed, what the athlete performed, and what the data recorded all stay connected in one record. Staffs managing very large rosters with very small staffs tend to feel this part first.
That record is shared across coach access and includes sport medicine and athletic training notes, on a platform built to be HIPAA compliant. In an environment where performance staff, medical staff, and the front office all need a view of the same athlete without three separate exports, that matters as much as any programming feature.
The point
Programming software gets a workout from a coach to an athlete. That is a real job, and plenty of platforms do it competently. What almost none of them do is close the loop between what the data says and what the program does, which is why so many organizations still run their real thinking in spreadsheets alongside whatever platform they bought, and why methodology degrades every time it moves down a level.
FYTT is built the other way around. The Metrics Hub is what makes the data usable, Automations is what makes it act, and Plans are what keep it coherent across a two hundred day calendar and a roster that never stops moving. A coordinator still makes every decision that matters, because he defines the groups, the thresholds, and the branches. The system just makes those decisions execute the same way at every level of the organization, without anyone re-entering them one athlete at a time.
See it against your own organization
If you are responsible for a methodology that has to hold across a complex, several affiliates, and a big league staff, FYTT can show you how the platform maps to the structure you already run. Book a walkthrough and bring your real group structure and testing battery, and the team will build a piece of it with you.
