Recently, I had a conversation with a friend and former co-worker. He’s essentially been running a one-man shop since I left there but the company had recently hired a new developer who claimed to be very experienced in the technologies to which the office is trying to migrate (notably .NET). My friend had been tasked with bringing the new employee up-to-speed and working with the current projects. However, there have apparently been some concerns that the new employee may not have the abilities he claimed in his interview (because it is a small shop, there was no formal technical interview) and that the new employee may not have the necessary soft skills to fit in with his co-workers. My friend asked for my opinion on the situation (since I worked there previously). Apparently, his concern was on how far he should trust the new employee in terms of working on various applications.

I had to stop and think for a little bit because I had never previously considered how others may do things nor on the trust level needed to work with others. I should caveat my commentary here by stating that, up until my current position, I had worked mainly as a cowboy developer in small one or two-man shops. When I had to work with others, there was an implicit level of trust and communication because that is how I deal with everyone. Until you prove to me that you cannot be trusted, I expect that you will do what you say.

That being said, I considered the idea of trust in an IT shop. Everyone has heard stories of developers who work to ensure job security by keeping all information to themselves – even to the detriment of the company as a whole. I do not subscribe to that theory. When my friend was first hired at my previous employer, it was my responsibility to bring him up to speed and to ensure he could do the work. From the outset, I worked to communicate with him constantly on various projects so that, if I were to be hit by a bus, at least someone would know what was happening and could continue. While I am not great at documenting my code, I tried to ensure that the code was at least documented to the point that a beginning developer could read it and have a good idea of what it did. And I made myself available for questions at any time and tried not to show any exasperation if the questions seemed – for lack of a better word – stupid. After all, there is no such thing as a stupid question, just stupid people. And stupid people don’t ask questions.

I checked up on my friend’s work until I was comfortable with his level of knowledge and understanding that he could do the work independently. As I sensed that he was ready to move up or move on, I allowed him to work on larger or more complicated projects. When I left the company about 2 years after his arrival, I was comfortable that he could take over my responsibilities without any significant performance hits to the department – and made my boss aware that, while she may miss my contributions, my friend was more than able to take them over. Could he do everything I could in the same time frame? No, but that did not mean he could not do it at all. But the key point is that he was able to grow and develop on his own. I learned that mentoring new people was an important aspect of IT as it forced me to understand the process well enough to be able to explain it someone else.

And none of that would have happened without a level of trust. Trust on my part that he could do the job he said he could when he was interviewed. Trust on his part that I would make him not only a part of the team but that I would help him to continue to learn and develop. Trust is not an easy thing to have and it is far too easily broken, but without it, the IT world would not be where it is today.

After all, open-source technology is probably a direct result of trust…