In previous blog posts, we discussed how to recognize when your IT team is under excessive mental stress and the risks this creates. They might be busy all day long but in truth they’re getting little “real” work done, and eventually they end up burning out. So what can you do about it?
A major source of overload comes from tasks unrelated to your developers’ core responsibilities. Instead of focusing on creating great applications, they’re also expected to manage all the practicalities of getting their software into production, for example. These tasks increase the external mental burden on your IT team. At BRYXX, we recommend automating as many of these tasks as possible with an internal development platform.
TECHNOLOGY IS NOT ENOUGH
Automation helps to reduce the external mental burden, but it doesn’t address the internal mental burden that comes from the complexity of the core task. Developers often have to juggle work on many applications at once. To reduce this strain, you first need to define your company’s value streams, such as the end-to-end invoicing process, for example. Defining these streams isn’t always easy though, especially for companies still working with highly interconnected, monolithic IT systems.
The solution is to move away from working on that single big system, so that your specialized developers no longer have to work on every module of every value stream. So you wouldn’t task a single Java developer with developing all your Java applications. Instead, you’d create stream-aligned teams with specialists who can cover every aspect of IT for that value stream.
The platform team provides the internal development platform we’ve mentioned earlier. Then complicated subsystem teams are free to manage complex, specialized technology, and enabling teams can be given the time to explore new technological opportunities that will add value for the company.
TEAMS COLLABORATE
These teams work together in several ways. First, each team offers its expertise as a service, “X-as-a-service”. To support this, they build a team API, essentially a set of agreements that clearly defines the team’s deliverables, how others can work with them, and the communication channels they use. In addition, they build technical APIs that allow other users to integrate their modules.
Of course, some teams need to collaborate more closely than others. For example, payment and invoicing teams often work hand in hand, even regularly meeting in person to coordinate. The enabling teams focus on facilitation, not only to discover new technological possibilities but also to teach other teams how to develop in new ways, sometimes under their guidance.
HOW DO YOU GET STARTED?
By combining automation with a fundamentally different team structure, you reduce the mental burden to a much more manageable level. So the challenge is: how do you implement all of this? At BRYXX, we’ve developed a phased approach. First, we help map your value streams. Then we select a pilot stream and assemble a team for it. If that pilot is successful, we use it to secure management support and then scale up.
Conway’s law reminds us that system architecture mirrors organizational communication. So we use teams to build the organizational structure, shaping it around the system architecture we want to achieve. We do this without any major reorganization, using a step-by-step process, eliminating unnecessary work, and deploying freed-up team members where they’ll add more value and come under less mental strain. Finally, we carry out annual audits to map progress and identify any areas for improvement.