Its been 3 months I have written a blog post. The reason of the delay is due to that I experienced a lot of crazy stuff lately by people who are just incompetent. Its like I am a wife doing the housework while my husband is cheating behind. I am a software developer by nature like a wife doing their own housework. But like a wife sees stuff like cheating, main housework is not the only important thing anymore. Instead, keeping the integrity of your husband is more important. And yet your husband may tell you to ignore what he is doing and tell you to keep focusing on your housework and make sure the meals come on "time", do you think you can still abide to that husband and trust after all what he has done? That is what I am experiencing. It would have been okay if this happened only once or twice, but this happened a dozen of times. It has reached to a point to scream out and say "This has been gone out of control! I cannot see my husband daily cheating on me!". And although this is metaphorical, this has become in a literal sense in real life (i.e. Tiger Woods).
A general prescription you should follow in your software developer life
Take the above story to a literal sense: In most software companies, software engineers will work on teams where their work is not integrated to the company culture productively because nobody cares about the company culture. Instead, they only focus on the technical aspect and ignore the people aspect of things. Add to the fact that most management also focuses only on the technical aspect, they have two paths which they can pick and do:
- A. Focus on the technical aspect. They become unhappy later on but they don't know why. Then they voluntary leave and they leave the company's culture intact.
- B. Besides focusing on the technical aspect, focus later on the people's aspect and make an impact on the company's culture and live with the consequences it brings.
While retaining "A" is on your best interest in order to grow your technical skills, you cannot grow your people skills well enough if you only follow "A". The many turnovers and failed projects that exist in corporations today makes the demand of "B" staggering important while the demand of "A" the least to the interest for you to pursuit too much. Although "A" to an extent of degree is important to know adequately enough to bring on deliverables, "A" is not enough "because to whatever you are doing" has not been analyzed whether it applies well in the current context and situation your company's problems is facing. I repeat, it ignores whether is approachable, appropriate, practical to the current maturity of the people behind working on this project and the helpfulness on the current context of the organization. Many heavily followed only on "A" and I have seen its perils.Within a year I worked on one organization, two big projects that were put for production and have retained for long have heavily been failed: One project was on the front end initiated a year ago and another project was on the back end initiated around the start of this year.
Given from that, over the past 4 years working as professional software engineer, I am a more distinct software engineer compared to others. I put emphasis on working on path "B" to the point my technical skills are not so good as others who follow path "A", but they are bare enough to bring deliverables while at the same time bringing value to the corporation that others can't match with people that only follow path "A". I tell you and I repeatedly tell you that I am very confident on what I am saying and the reason why all my blogs talk software engineering in the principles of path "B" is this: There is a huge demand on solving the so called "political problems" in the organization, as they create huge inefficiencies, high turn over and a lot of dozen failed projects. It is most likely that management has a lot of stuff on their shoulders and they cannot solve all those "political problems" by themselves or most likely neglect them to the point of only caring their own responsibilities and hurting the whole organization in the end. That is why organizations started to create cultures that are flat and approach an organization that follows "holocracy" (because it is "holy"? Yes, to some extent it is). That is why I am telling you that even if your organization is all hierarchical, you can still follow those practices that I have mentioned so far in my blog. In other words, to follow path "B".
I am not sure how the future of software development world will be, but I have seen that currently there has been a huge negligence in the management world to follow path "B", that is, to bring a balance, to follow the "executive paradox" mindset. Instead, management focuses a lot on path "A". At the same time, IT employees focus on path "A" religiously. I don't know how our society created a ridiculous culture. Maybe it is due to the pace of the technology where each improvement saves us more costs and is more efficient (some do not explain the gruesome complexities behind those technologies), maybe the bombardments daily to learn new hacks you can use of a specific technology, maybe that our kids can play all day for free on the internet learning new programming languages (it is not "free" et al, it is so they can "convert" themselves and the future companies that they will work to use "this" type of technology that the employer has to "pay" licenses for). I have an anathema for the ones that follow religiously on path "A" all the time. It is not good for themselves or for part in society. In the long run, it will not be your best sale point on your career as there are already many supply who follows that path. The only way to make the distinction apart from the others is to follow path "B".
Let me tell you briefly why I converted myself to path "B". After I graduated, I never thought that I would have to face path "B" in my entire life. I thought management could cover that. I thought just doing "A" will be enough and get rewarded on my efforts. This does not happen in the corporate world. In fact, after my first 2 years working, being negligent willy happy on my own lala world, I noticed I got punished instead of being rewarded. What consequence could it be that when I followed my duties that I got punished? It is not attitude or other stuff people tell you. Ironically, they are just excuses so you never need to explore path "B". I started following path "B" from the day I started my own blog. I started path "B" after 2 years of working on my first job. By that time, it was too late for me to fix my ineffectiveness to the organization I worked before. Yes, I say "ineffectiveness", yet although my boss told me to follow Path "A" and I followed Path "A" extensively, I should have followed Path "B", even when bosses would start to dislike it at first. One of my first blog posts was describing a dream I had before, a dream that told me to either listen to bosses telling you to follow path "A" or you are out. Of course, this is not the correct remedy to work efficiently on your organization, especially with management that do not handle the company culture effectively. As long they ignore following Path "B", no matter how hardworking or experienced your employees are on following Path "A", it will not really solve your business problems. On my second job, after working for more than a year, I started to follow path "B". I started to take initiatives that contradicted the advice of management and even lately raised my voice. For as those who followed meticulous the advice of management, they lost their moral and resigned in the end. That if I followed the advice of management, I would have worked on a project that is now considered a failure. However, following path "B" is more of an adjustment or being adaptive to the current situation of the organization. You cannot follow it immediately. You can only follow it after you know the corporation well enough and can make progressively adjustments to that end. It is a slow pace transition from thinking in terms of the people aspects of things within this organization instead of just only the technical aspects of the organization.
Lastly, because we are living in an unbalanced world, like the "unix manifesto", I think there is a huge demand for organizations to work as follows:
- Management to focus 80% on Path "B" and engineers to focus 50% of their time on Path "B"
- Management to focus 50% on Path "B" and engineers to focus 25% of their time on Path "B"
This prescription has no sides
An important thing to mention is that this prescription has no sides. This prescription does not say to follow to communicate all the time with customers (agile) or to follow a project until its full completion (waterfall). Actually, both of those practices if followed by word are not effective and it is usually somewhere in between that you are the most effective (i.e. Complete stuff on time but read your environment for new opportunities and threats daily and adapt as quickly as possible).
In any case, let me tell you my story. I "switch" political sides. I do not retain on the same political side forever. Some organizations are too agile (like my previous company) and some are too structured (like the one I am currently experiencing). The aim is to put a balance and do what you have to do to change political side to the one that fits more appropriate. That is why many job descriptions these days tell you to have experience both on agile and waterfall methodologies, as they both have its huge pitfalls if followed solely (when I mean "agile" here, I term the bad acronym of "doing agile" instead of "being really agile"). And although some management think again that changing political side means only changing the technology, it is usually instead changing the people that you are tagging along with, as usually most people stick only to one political side and they don't change no matter what new technological revolution managers embrace. Some people are very hard wired creatures, embraced to only one side of coin of things inherited by culture or upbringing. It is very hard to tell them to stretch instead of snap, such as the executive paradox book describes. However, you can always tell them about it that they are doing it wrongly, and although they may be effective currently, statically, for most of them, they will take your advice by word later on, as rolling those dices again and again will not make them effective or they may have contributed to a less greater good to society within their career line if they played it psycho-pathetically.
On my previous job, before I quit, I played as an extremist to put structure into place. In my company that I currently work for, I played as an extremist to care about the collective level of people needs into place. I changed roles. Although others may feel like I am a traitor, like when politicians switch from one party to another, that is not the case. It is reading the situation. Here is an example: The current prime minister in Greece was a strong socialist not accepting any of the reforms set by the European Union. However, all of a sudden, he changed his mindset and agreed to the reforms after huge pressure with capital controls. Why he changed his mindset? He read the situation. He knew that if he didn't followed the demands of the European Union, he will lose his political leadership and any substitute of any other political leader would do worse to care for the collective level of the people. After that incident, re-elections came and besides all the losses he did to his country due to capital controls, he got re-elected. He got re-elected not for his strong socialist ideologies, but placing his strong socialist ideologies before others to the current situation of things, to bring balance back to society.
But most of all, I can give you examples that this prescription has no sides from my own experience and from my own doings.
You can look at the side when I was embracing structure on my previous job and embracing agile in the introductory use case I just written today bellow Digging holes for creating graves to on board crew and newcomers
Introductory Use Case: Digging holes for creating graves to on board crew and newcomers
I had known the whereabouts of companies that do a lot of stuff for their customers, but not a lot of stuff in planning ahead of how to retain their own assets. Specifically:
- Planning ahead on scheduling a time frame where they appreciate others fixing technical debt.
- Planning ahead whether their business model is sustainable or not in order to fund themselves and especially their employees to the average market salary.
Today, I am going to talk a different story. Today I am going to talk about companies that fix technical debt too much without caring the people's needs. To put it in real words, I am pretty outraged some companies have a mindset that does not care about the people of the organization. Their attitudes and looks may all be corny with good will and faith only to just boost their self esteem.They act that they actually do care about people, but honestly they do not. Over a year, I lost contact to a lot of direct and indirect employees that I worked with closely within the organization either by themselves voluntarily leaving and in few cases being fired. I am going to classify the people into two type of categories: what type of technology they worked mostly with (back end or front end) and how much related they were to me (same department or different department). In either case, all of them where very closely affiliated to me.
- #1:Back End/Different Department (Left September 2014): This person was in a different department from mine and worked on main reports that still retain or were derived a little bit to this day.
- #2:Back End/Same Department (Left October 2014): This person worked as the main lead in a lot of insights and pushed people to develop intelligent systems that still retain to this day
- #3:Back End/Same Department (Left December 2014): The main person that created a sustainable data-warehouse with minimal staff that is still in use today and is expected to be replaced by a new one.
- #4:Front End/Different Department (Fired January 2015): Was working alone on a new restructured/refactored front end database architecture that could be used as a replacement for our main service.
- #5:Back End/Same Department (Left June 2015): Was working on a main portal infrastructure that generated and uploaded small reports for external third party business partners.
- #6:Front End/Different Department (Left July 2015): Was mainly in charge as the lead of the operations within the front end.
- #7:Front End/Same Department (Left August 2015): Main guy that configured the intelligent systems to be run on the main service. Worked later on Quality Assurance.
- #8:Back End/Same Department (Left October 2015): Main guy that worked on improvements on the architectural and server part of the data-warehouse that is expected to be replaced by a new one.
- #9:Back End/Same Department (Left October 2015): Mainly did a lot of supporting technical tasks for the back end.
I do not have to say a lot of words, but yikes! Seeing 9 people that "you know directly" are leaving makes you really discouraged to work no matter where you are from. Imagine how many people that "I do not know too much" have left? I do not know, but definitely, these are not numbers any organization can hardly digest.
Why this happened? Obviously, like I said before, they ignored people's needs. They focused on two projects that were too ambitious where in the end failed disastrously. They made the rest of the employees who worked there be frustrated. Their main problem management focused is "How X technology is going to replace technology Y". They put the least funds, care, or appreciation of Technology Y which made employees who worked on that technology to voluntarily leave. These employees have the domain knowledge and it cannot be replaced easily be pen and paper. Any new employee will not have the same confidence as the ones who voluntarily left and worked in that company for years. Let mind you the turnover costs of retraining new employees. On top of that, that X technology they funded so much ended up currently to be a failure. So if you worked on that type of technology, it would have been a waste of time. Either path you take was a dead end for a period of a year. Instead of learning their lessons and caring about the people needs, they now are planning to create technology X to the power of two to replace technology Y. This is why I have an anathema of people who only think in technical aspects of things. Their habitual instinct is to neglect the people's needs. That damage they have already done and will do by feeding this cannibalistic habitual pattern will lead them to create an inefficient leadership.
So for a year, if they did not deliver effectively technology X, what did they deliver at least?
They delivered digging holes for creating graves to on board crew and newcomers.
Congratulations!
Why this happened will be elaborated on another blog post as it is too complicated, but the main points are:
- The reason for technology X failed was because of the ideologies of people on technology X was very hierarchical, structured, following a waterfall methodology.
- They cared everything to be perfect instead of having a working thing for people to use. They would never give something that was not complete which could have met some of the requirements to the stakeholders.
- They didn't trust the people that could use the product could be responsible or competent enough on committing to the main product. Everything was decided and communicated within internal developers, not within the people.
- They felt reward for owning the product instead of open sourcing the product and managing everything to run smoothly. Instead, they never shared their work to internal stakeholders.