Wherever I worked, I usually tested the hierarchy’s patience with my ‘going out of scope’. It started in secondary school, actually – I remember the day – when I had gone off wandering outside of the Chemistry curriculum (but within the textbook).

I’d been doing my own notes independent of the class – things that I found interesting. I didn’t understand a curriculum. I was just having fun learning, and so I had foolishly thought that my work would be appreciated when I showed my work to the teacher.

He wasn’t impressed, particularly since I wasn’t doing too well in his class. He wanted me to focus on the curriculum – but no one had given me a curriculum, they’d given me a book. He told me I would continue to get bad grades in chemistry until I focused on the curriculum.

What we both didn’t know at the time is that I didn’t care about the grade, I cared about learning stuff. This could have been a pivotal moment for me in formal education, but it wasn’t. That would come almost 2 years later when I decided I needed to pass their tests.

Similar stories followed me throughout my careers. I was never interested in what society thought I knew, I was always interested in what I could learn. At first, there was little benefit, but later on in my careers in Medicine (USN), software engineering (all over) and writing it came in very handy because I not only knew things that others didn’t, I also didn’t think like others did.

Since I wasn’t interested in their prizes, I didn’t have to play by their rules. And since I didn’t play the ratchet game of educational landmarks, I didn’t limit myself and didn’t stop studying things after I got to a certain point. So many people languish, letting the fluid education they have become concrete, set in stone.

In solving problems, this became my greatest strength – that I was immune to siloed knowledge. It drove managers and CTOs nuts at times, having a software engineer wandering around and talking to users and people who supported software, an unheard of thing in modern software development, but well within normalcy in the elder practice. Know the users, know the uses. Know how it’s used, know how it might break.

Plan for everything.

But sometimes it doesn’t work that way.

As a software engineer, I usually found myself in trouble with management because I was always doing things ‘out of scope’. I’d wander around at times, talking to people who supported or used software I was working on for a few different reasons. At one of the last companies I worked for, I was told repeatedly that upper management saw me wandering from my desk too much.

My Director at the time thought I was unfocused, and yet every project I was given was done on time despite my wanderings outside the building or over to other departments. He wasn’t wrong, he just wasn’t right, and in retrospect I think he wrote that to pacify upper management. Either way, I didn’t really care, but saying that was a great way to make sure I got a crappy raise.  I ended up getting a crappy raise anyway, but in a way that was my fault for not negotiating harder.

What had happened was pretty straightforward. The company had some complex software systems, and when I started the then most senior software engineer was on his last week. I learned as much about the systems as I could over that week, trailing him, getting to understand the big picture of the spaghetti code that interns had written. The few with true specialized knowledge held onto it as their job security.

I learned a lot in that week, but not enough. Nobody who was interested in solving the problems actually knew anything, nothing was documented, and so I began writing things down as I had been taught as a young Software Engineer at Honeywell. Some of it was accused of being wrong by those whose job security was threatened, and my response was that they should fix the Wiki. They never did, of course.

Things changed within the company, part politics, partly near revolt in the Software Department (another article there!), and so structures that were once fluid became siloed. This isn’t as much of an issue as people might think if people actually document what they do appropriately, and it’s shared with the department overall – so there were problems that arose because the software complexity, and entropy, had gotten to critical mass – and problems arose that required someone to be outside of the silos.

At around that time, I was asked to a meeting about some issues and I stayed quiet the entire time. One of the company’s officers asked me to stay after the meeting, and my Director was there too. He asked me, “Why didn’t you say anything?”

So I explained to him that since everyone was off doing their own things, and that I had no insight into how things were actually changing in the software across multiple teams, I felt blinded. Where once I had a working knowledge of the systems, I no longer had it because I wasn’t able to see what was changing, and how it would affect the systems on a larger level.

There was a silence. Nothing changed. And after a few system screwups that brought the entire system down, caused by undocumented and sometimes ill advised changes in the code by people, including myself (mine were documented)… I gave up.

I knew we were working blind. However, people who had never peered behind their version of Plato’s Allegory of the Cave couldn’t see, and because they couldn’t see, they didn’t care.