“Moderately crazy” was the polite description.
Shutterstock had grown, and the office network had grown right along with it. New teams, new equipment, new requirements, new exceptions. Each addition probably made sense when it happened. Together, they had become a system that needed to be cleaned up.
I sent the technical teams a list of questions before starting the rebuild.
Did operations and IT still need separate networks? Did development and QA need to stay apart? Did DevOps need its own section? Was anything still using the legacy setup? Did the database group need a dedicated network?
The questions were basic on purpose.
It is easy to treat old infrastructure like geology. The layers are already there, so everybody learns to work around them. A rule that solved a problem two years ago becomes permanent even after the problem disappears.
The IT operations group was getting stronger. That made it a good time to stop accepting the existing map and draw a better one.
I did not arrive with the finished design. The people using the network knew where the strange parts were. They also knew which separations were protecting real work and which ones were just history.
So I asked.
That was often my role as the organization grew: turn a vague feeling that something had become messy into a project with a list of decisions. Not every answer needed to be complicated. Some networks could probably combine. Others existed for good reasons we needed to write down.
The goal was not a perfect diagram. It was a setup the next person could understand without first finding the one employee who remembered why everything was built that way.
Growing companies collect old decisions quickly.
Every once in a while, somebody has to ask whether they still make sense.