Software engineering org charts have never been more complex. Gone are the days of large, stable teams that report to a single leader and work in highly structured ways on long-term projects.
Methods of working and styles of architecture have both shifted towards smaller, more iterative, or flexible atomic units (ex. waterfall to agile or monolithic to distributed).
These complicated org charts have supported the creation of incredible software over the last two decades, but not without trade-offs.
What do complex org charts obscure?
In short, engineering leaders with large, complex orgs struggle to easily identify bottlenecks or areas of high risk.
They may be able to use data to spot an individual team that’s over-burdened. But using data to know that the frontend group responsible for the recommendation experience across all their products has more tech debt than any other functional group?
Much harder. Traditionally this has only been achievable through time consuming, ad-hoc or bespoke reporting.
That’s why we’re introducing Groups–the ability to create custom team hierarchies, so your real org chart can be easily created and used in your service catalog and developer portal–to power reporting of any kind.
Organize your Teams into Groups
Last year we introduced Functional Teams to OpsLevel in order to account for the gap between HR org charts and the real, functional org charts that actually ship and run software.
Now with Groups, arrange teams into any series of nested groups that represent the logical or functional components of your organization. Your groups (and nested sub-groups) are primitives that can be used anywhere in OpsLevel:
- to return a list of services or repositories
- to filter the Service Maturity Dashboard
- to scope campaigns or checks to particular services
Like teams, each Group can have an associated manager(s) and markdown description for storing charters, missions, or links to other relevant resources as shown below (contact information remains at the individual team level).
Learn more about the nuts and bolts of Groups in our documentation here.
Setting up Groups
Like most parts of OpsLevel, Groups can be configured and managed in a variety of ways:
- directly in OpsLevel’s UI
- via our GraphQL API
- via our Terraform provider
- via our Command Line Utility
Example: Groups via OpsLevel’s Command Line Utility
We know that many organizations today don’t have a single, reliable source of truth for functional org chart information, especially complex hierarchies. We believe OpsLevel can fill that gap; in addition to the new Groups capabilities outlined above, our tooling is designed to handle your org chart data, no matter where it comes from.
In this case, we’ll use our Command Line Utility. It’s designed with extensibility and composability in mind, so you can adapt this pattern to your use case. This script below applies specifically to creating OpsLevel Groups based on data retrieved from the GitHub Teams API.
At a high level, the script:
- Takes in JSON from the GitHub Teams API
- Creates new OpsLevel Groups for each record in the JSON payload
- Correctly places any nested Group within the hierarchy based on values in parent.slug
#!/usr/bin/env bash
TEMP_FILE=$(mktemp -d)/group.yaml
TEAMS_DATA=$(gh api -H "Accept: application/vnd.github.v3+json" /orgs/OpsLevel/teams)
for row in $(echo "${TEAMS_DATA}" | jq -r '.[] | @base64'); do
_jq() {
echo ${row} | base64 --decode | jq -r ${1}
}
cat << EOF > ${TEMP_FILE}
name: "$(_jq '.slug')"
description: "$(_jq '.description')"
EOF
cat ${TEMP_FILE} | opslevel create group -f -
done
for row in $(echo "${TEAMS_DATA}" | jq -r '.[] | @base64'); do
_jq() {
echo ${row} | base64 --decode | jq -r ${1}
}
if [ $(_jq '.parent.slug') != "null" ]; then
cat << EOF > ${TEMP_FILE}
parent:
alias: "$(_jq '.parent.slug')"
EOF
cat ${TEMP_FILE} | opslevel update group "$(_jq '.slug')" -f -
fi
done
rm ${TEMP_FILE}
Unlock insights & accelerate adoption
OpsLevel customers who used Groups during our beta were surprised at how much value the feature unlocked for them. What happened? People make change, not technology.
So getting the right data in front of the right engineering leaders can be a simple way to accelerate your Service Ownership or Service Maturity projects.
Ready to see for yourself? Request your OpsLevel demo today.