On Pragmatism

For most of my careers as software developer and software development manager in the application development area, I tried to be pragmatic in the decisions I made and the paths I follow. Unquestionably, it served me very well to move forward in project executions and business problems resolutions. Time and again, I followed my gut and tried to be pragmatic at heart. I still remember and approve some of the decisions that I made in the past based on pragmatism – for small tactical problem resolution; when time is a big factor to provide solution; when short term gain is appropriate; and so on.

Various definitions of a pragmatist person includes: one who acts in a practical or straightforward manner; one who values practicality or pragmatism; one who acts in response to particular situations rather than upon abstract ideals; one who is willing to ignore their ideals to accomplish goals.

Web dictionary defines pragmatism as:

1. character or conduct that emphasizes practicality.
2. a philosophical movement or system having various forms, but generally stressing practical consequences as constituting the essential criterion in determining meaning, truth, or value.

Based on the definitions above and from my own experience, you may take that I like being pragmatic. I am indebted to all the benefits I ripped from being pragmatic in the past. I still believe being pragmatic is appropriate and beneficial in certain circumstances – most beneficial for solving tactical issues. But, I am realizing that unchecked pragmatism can be dangerous in the long term.

I am recognizing that pragmatism also:

• limits solutions at an average level since solutions are not well thought out and solution devised as a continuation of what already exists
• hinders progress by keeping one to the area that is well known and hence prevent from exploring new ideas
• confines one to think in myopic terms or making one to be purposeless as opposed to having a forward looking and drive things toward a bigger goal
• justifies short term gains over the long term benefits; as many of software development professional remember, there is a phrase coined in software development called ‘technical debt’ that I believe mostly a product of being pragmatic
• limits, above all, one’s ability to innovate.

Michael Wade in his blog describes pragmatism’s problems. Wade states five problems with pragmatism (Wade provides fair explanations on his post):

1. Pragmatism can be a convenient cloak for opportunism.
2. Pragmatism can lower performance standards.
3. Pragmatism can encourage a "can do" attitude that sacrifices action for thought.
4. Pragmatism can be tiring. The rushed nature of pragmatism can be exhausting.
5. Pragmatism can encourage hubris.

In conclusion, I am not discounting or ruling out being pragmatic – on the contrary, there are many situations where being pragmatic is applicable. But, you need to understand also that it limits one to an average status if kept unchecked and continuously applied in the long run. It limits thinking to be quick action oriented where an average solution is usually the outcome. It encourages a status quo or limited progress since it is evolutionary by nature. Be aware of these facts – be pragmatic on these facts.

On Enlisting Others

Leadership is said to be influencing others to participate, contribute and reach to a shared goal. Do not take this as a definition but as one of the many explanations that is out there on leadership. I have seen this in practice and the below is how I captured the approach. I know that I am running the risk of oversimplifying what leadership is - but here it is.

If you are in a leadership position and if you have an idea, share it with others and if necessary repeat it with them so that they have it in mind. Try to make your idea to be understandable – making it concrete using data or using beautiful explanation. Try to make your idea visible, put your idea somewhere, and ask people to comment on it. Then, enlist and ask people to participate in a brain storming session to discuss the idea, and generate next action items. Try to illicit others to take up on action items and provide feedback.

At this point, the idea is shared, amended, and possibly accepted and supported by others. If this is the case then it will cease to be your idea and becomes 'our' idea. You have passed the biggest hurdle and you are on to the next step. This is where you have to be careful and meticulous - you are getting into the execution step. Most ideas do not get implemented due to lack of will or participant, among other things.

Illicit execution ideas the same way from others, especially from those who saw the benefit from your idea - guide on what needs to be done and leave the ‘How’ to do it for participants. You can count on excellence in execution when people are choosing and allowed to provide feedback on implementation approaches. The main point here is to make them to feel like they own the idea as well as the implementation. Once execution is started, your task is to motivate, provide constructive feedback, be active participant – chances are the implementation process will be enjoyed by the participants and success may be achieved.

Remember - people strongly support what they help to create. This means they contribute with what they have to the implementation and thus to the success of what they set out to do. This is true in the case of failure or success. Credit for success will be shared and failure does not cause finger pointing.

Currently Reading: A Political History of the Tigray People's Liberation Front (1975-1991) by Aregawi Berhe.