I recently was working on a project and got in one of those discussions where I was not communicating at all. I was trying simultaneously arguing that the software was something I could build, but one that would not work. I felt pretty confident in my abilities to build and deliver it, and, in fact, that it would be pretty cool once built.
However, I was also trying to indicate that because of its complexity, it would have the characteristics of an unstable nuclear isotope – it would not last long. The system in question wold require so much more human intervention to keep it correct than was available within the organization that every month of operation would put it further and further out of true. It was ‘Possible, but not Practical’.
Earlier in my career, a fascinatingly intricate project like this would have captivated me, and I would have pushed through regardless of the practicality of its operation. However, two things conspired to prevent me from doing this. First, the experience of building it made me question its foundations and whether the end user really had a grasp of how complex it was, since I was supposed to hand it off to the business once it was done. Second, our management evaluates us not only on ‘planting the tree’ but also on ‘having it grow’.
This approach has taught me to look and ensure that the tree that I was planting would, in fact, bear fruit. Here, I could tell, that I would be tending to this particular tree for a very long time.
So I found myself arguing both for my ability to build the software and deliver it on time, and against the advisability of doing so.
After a half hour of discussion, I realized that this superposition of two seemingly contradictory points was not effective communication, so I moved to a ‘No’ and stopped arguing that this was possible, because no matter what I did, the nature of the software wasn’t something that could work.