Software Engineering: Expectations mis-match
I once had a “Sr. Principal Engineer” that was moved to my team as part of a large merger and team reshuffle. She had over 25 years of experience. My first line of approach was naturally to get to known my new team members and in asking her how a typical day is spent, she said something along the lines of, “It’s a new challenge everyday. We have 6 spreadsheets that have thousands of new records everyday. None of them are structured and I have to going and clean them up manually to make them exportable to another system that needs them in a certain format”.
She had been doing the same thing for the past over 5 years. My immediate reaction was, why she had not automated the process in all these years, to which she said, “Oh! It has always been like this. Plus no one asked me to do it. And they don’t pay me enough to do it”. When I tried to challenge her thinking, she started taking offense and took a posture of defense followed by resentment and non-cooperation.
I will leave the rest of my conversation with her to your imagination… I let her go in about 3 months from that day.
I became hugely unpopular amongst my new team mates. I also had to explain myself to my boss, the CTO and to the HR Director. But the company loved me! And the engineers that saw the honesty and openness behind my challenge, started following me. Some of them work with me till date and for over 10 years, have followed me to other organizations that I moved on to and then to the company that I started.
I, in essence, made a statement that I hold my Engineers to a standard that Engineers need to be held to! Needless to say, this is a story that has about a similar sequence of events, with the ‘firing of the engineer’ portion left to the discretion of the manager or the organization in question.
If a task, regardless it’s complexity, can be replaced by an automated program, the Engineer must be replaced by an automated program (unless there is not a justifiable business case).
This is a familiar story to most managers and engineers in the Software Industry. I see experienced and expensive Engineers applying little to no thought to why they are doing what they are doing.
Engineers in general count their contribution in hours of work or the length of time they have been loyal to the organization: a metric that by itself, holds little value!
The mark of a professional is in being able to gauge himself or herself in terms of the value he or she is bringing to the mother ship. It’s not about how long you have been there or how many hours you are willing to put. It is about the value add. It is about the impact!
Just as doctors are to save lives and policemen are to protect lives, engineers are to impact lives!
A software engineer’s primary responsibility is not to build products. It is to make life easier and more valuable by eliminating what is otherwise very difficult.
I ask every engineer
