Character Not Characters

This is a departure from my usual topics. Providing support (my generic term covering all the “C” acronyms: Customer Service, Customer Success, Customer Experience, etc.) will always be the responsibility of the team that is responsible for these tasks.

Sure, there may be a “manager” role involved, but ultimately, it will be about how well the team works together, and apart, to provide the most assistance and, yes, support to your customer base.

Although experience can be significant, this is another potential fallacy: Knowing the product beforehand will not give you the knowledge you need to assist another person using it. A good manager can train any of their reports to understand and use the product as it was designed. This requires intra-team communication to ensure these intended functionalities are accurately described.

Keep in mind that the properly prepared underlying documentation will be the training resource. This again points to proper integration between the relevant teams.

This integration is going to be supported by the character of the individuals working together. This is not about employees being characters but the moral and intestinal fortitude and the commitment to their organization, i.e., their character.

A person of character can be trained. They can be incentivized with the proper management. They can be provided the tools to succeed and left to do that.

Persons of character will succeed if provided this impetus and allowed to shine. They will provide more successful and innovative approaches than any amount of forced management of their skills could ever present.

Persons of character will always be a boon to any organization but beware of characters that are not about the organization. Their thinly veiled intentions will always shine through under scrutiny. They will show themselves in unexpected ways, and it will be challenging to make the hard decisions that need to be made.

Character versus characters: choose the former to succeed; do not give in to the latter.

Written In Whatever Works

yes written in the sand

Wow, it’s been a while, but I’m back… at least for this post.

There are times when it does become a question when trying to establish guidelines if you are taking the “written in stone” method or the more ambiguous and flexible “written in mud” approach.

“Written in stone” implies this is how it is, and there is virtually no wiggle room for you to move outside the guideline. You essentially have to work within them which is excellent in the beginning. However, as time goes on and things evolve, you might start to see bits and pieces of your stone tablet starting to chip away.

Those strong and idealistic guidelines proved very helpful in establishing your processes and creating the environment you are working with. However, they also may have become even more restrictive than you expected as these guidelines now control your work versus you controlling the work product you want to produce.

Hence, the idea of “written in mud” comes to light. Yes, as the phrase implies, it could get messy. Still, because it offers some ambiguity and more flexibility than the stone practices, that messiness allows you to try out new things within reason and carry on with your evolving workflow.

Your written-in-mud guidelines can evolve with the times versus needing to be carved out of another stone tablet that will likely fall prey to the same ravages of time the first set of written-in-stone guidelines did.

Which approach is best for you and your projects will ultimately be your decision, although it will eventually come down to the approach: written-in-whatever-works.