I had an interesting discussion yesterday with three educators. The topic was the oral and written communication skills of young adults attending college.
Each of these women teaches English in a Midwestern college or university.
Each told story after story of their frustration with today’s youth and their inability to communicate verbally – and in writing.
One particular story that is now stuck in my head is a student’s request for the teacher to read their paper in class so they would not have to read it themselves. My friend (the teacher) firmly believes the student did not want to read their assignment because they could not accurately pronounce all the words within the paper that they had just written. She thought that the student felt as if they had done enough by writing the paper and that it was “fair” to ask that the instructor read some of the paper to the class.
There were other discussions between the four of us about poor sentence structure, too much texting, inability to hold a meaningful conversation for any longer than about three minutes and too much Xbox.
I felt I had to chime in. I told them about my experience earlier in the afternoon. I was in the final stages of our on-boarding process with a potential new hire candidate. The position we are hiring for is software developer. This particular candidate had performed well with the various technical aspects of our recruiting process. We were now at the R & D/writing assignment step. The document that was submitted left much to be desired. Not a lot of effort was put into the deliverable. Sentence structure was poor. And to top it all off – our recruiter had to send the document to me. Why? Because the candidate had a typo in my email address – and I never received their initial submission.
Issue: New software functionality needs to be added to your enterprise content management system
Option one: quick, “down and dirty” approach that will most certainly cause issues for all further down the line
Option two: a more thorough design approach that will take longer than option one (above)
Option one sets us up with a technical debt according to Ward Cunningham. Technical debt is quite similar to a financial debt in that they both have interest payments in common. What I mean is that there will be additional effort and time spent in the future because of the initial design choice.
Again, we are presented with two options.
Option one: continue to pay the interest
Option two: pay down principal by re-engineering the initial design into the improved design
Real-world example: customer timeline is short. New functionality built. Parties agree to deploy phase one deliverable into development environment. Initial timeline met, code delivered to client. Client deploys code directly to production environment. Issues occur that increase stress for both parties.
Technical debt can be good or bad.
What makes this so interesting for those of us in the consulting field is that we must deal with technical debt while also reconciling it with the financial restrictions and timeline necessities of clients. Meaning, we all need to be aware of this debt, and inform customers of this debt, but we will often need to live with it as a reality despite “knowing what’s best”. This is written with complete humility. Why? Remember that we have been hired for our expertise.
As an entrepreneur in a highly competitive industry, we’ve learned that “good business” refers to positioning your business for greatness – and more importantly, always doing the right thing. At all times, the right thing to do is to think long-term for the sake of:
If you treat people right and always do your best to give your best effort, new opportunities will present themselves. Additionally, make sure these opportunities are the right type of business your company to make a lasting impact.
In the end, always take the high road and do what’s best for ALL parties involved, even if it isn’t lucrative at the outset.
That’s good business, and that yields long-term success.