Software is a complex sociotechnical system. It’s not just code, or servers, or people, it’s all of those things and how they relate.
Layoffs are a really hard time for both employees and companies. We always feel for the people who are out of work -- it’s scary. We even feel bad for management who cannot get around the need to lay people off, and have to select their teammates, and sometimes themselves, as the people to lay off. We also should spare a thought for the people who stay behind, who have to keep everything going with fewer resources and fewer teammates.
Software is a complex sociotechnical system. It’s not just code, or servers, or people, it’s all of those things and how they relate to each other. Layoffs are a significant disruption to that system, and we need to figure out how to respond to that in both human and technical ways.
Who owns this code?
You can use OpenContext to figure out who owns what, once the dust settles. What services, what code paths, what infrastructure rolled up to someone, and how do we need to rebalance that load? If you lose half your team, the half that remains can’t automatically pick up everything at once, they need time to transition and reprioritize.
Managers and technical leads need to be able to assess their code structure in light of the remaining developers and team members, and redistribute the work fairly and logically. What things should get dropped due to lack of resources?
It needs to be easier for teams to see all the interdependencies of services teams so that they can make better decisions on how to divvy up responsibilities mindfully.
Managing change in difficult times
Having a good map hopefully helps teams understand how to keep things running after a re-organization. Onboarding is easier if you can see the context of the new service you’re managing. Theoretically, people have time to train for their new responsibilities as part of the transition, but that doesn’t always work out in practice.
We need to do continuity in a way that doesn’t entirely depend on humans.
If we make it easier to self-serve and self-discover context with autodiscovery, we are empowering everyone dealing with a new system, whether it’s because they are taking over a project, switching teams, or starting a new position.
Avoiding surprises
Code autodiscovery is a way to avoid surprises. Even people familiar with the codebase need to check that their dependencies have stayed stable. Sometimes other teams move things that you use, and it’s great to be able to check and find the things you depend on.
Autodiscovery may also surface things that you have either forgotten about or didn't realize were in there. As time goes on projects change and evolve, and sometimes things are left behind. Priorities change. The entire organization may gradually forget about some parts of the code base. You need mapping to be able to tell if they could just be deleted, or if they’re important to some other part of the system.
How often have you pushed a new release, and after deployment, something obscure breaks? It happens because we can’t keep track of all the dependencies. But if you had known your dependencies during product development, you could have planned with the team in charge of that dependency, and collaborated on any upgrades or updates or security changes that your new code needed.
Reducing the system impact
It’s never going to be easy to lose teammates, or to have to take over work that was abruptly dropped. There is a lot of emotional work that goes into carrying on the work of the company. One of the things that we hope is that creating tools to help map your system makes the technical side of that work easier.
Top comments (0)