24 March 2017
After 7 years of working for Experian, I’m finally moving on to the second job of my life. I’m capturing the learnings and observations throughout those years here, something that I’ll be able to look back on to remind myself in the future.
Most of us live in a non-programmer-friendly society. We have words like geek or nerd which have negative connotation to dis programmers. You are socially expected to have life after work. Of course, programming or contributing to open source are not counted as life. On the other hand, most of the programmers I know are introverts, meaning they are quiet and will naturally not talk about their passions. These two factors cause a vicious cycle which worsen our society.
To break that vicious cycle, we who love programming, should break out of our introvert bubble. Talk about your passion more and don’t be shy talking about what you are developing at home. Give some tech talks to your department. You might not change the society much, but you would inspire the others who love programming to do the same. There are a lot of good things that wouldn’t have happened in my career if I did not show my passion. I’ve got to know a lot of good programmers. I met passionate managers who have kindly given me guidance. It might be why I was hired as a Software Engineer despite being a fresh graduate.
I had met colleagues who would complaint about how underpaid they are. The innocent me would ask, “Why don’t you ask for more?”. More often than not, the answers I’d get back is:
“That will never happen.”
There are way too many people I met whom somehow expect good things to just suddenly happen. In an ideal world, yes, you will get what you want without asking, but most of us will not have that luxury. You’ll have to ask for what you want. If you don’t really know what you really want yourself, I would suggest you to figure out your hygiene factors and motivators.
Now, I don’t claim to be a negotiation guru, but the simplest thing you can do is just go into your one-to-one meeting and say:
“I’m feeling underpaid.”
There are definitely better ways of getting a raise, but the problem in the first place is you, thinking that your manager is a psychic who are capable of reading your mind and figuring out what you want. Be reasonable of course, it only works when you think that you have given more than what the company gives you. You might not even need to justify anything if you have shown the quality of your work.
Looking back, I have switched my role to become a build engineer because I asked for it. Initially I only asked for a part time role as I figured that there are a lot of room of improvements which can be solved with my software engineering expertise. I was then involved in the build engineering team. After I have provided enough data and evidence that I’m suitable for the role during that part time hours, I finally asked for a full time role change. Even after the role change, I asked for my job scope to be changed by including more engineering and reducing administration tasks. I gathered data from the internet on various companies’ build engineer job descriptions then ask for the change.
The manager’s function is not to make people work, but to make it possible for people to work.
― Tom DeMarco, Peopleware
Good managers understand “flow”, the hard-to-gain state where a knowledge workers would be able to get complex works done. It is the development managers’ job to ensure that all of the engineers are able to enter the flow state. It is too easy for managers to be unsympathetic about no-flow problems, because they work in interrupt mode where no flow is needed. If you are a manager, you will need to be more observant to the office environment. For example, when you see an engineer wearing earphones, maybe the office is too noisy and he’s struggling to concentrate. All of the engineers will love you when they can get their daily dose of flow. Use your power.
I once heard from a manager about how surprised he were about a team that is incapable of focusing on their work due to the high number of disruptions occurring in a day. He eventually said that this problem is not solvable as it is a cultural issue. This is another example of an unused power. It is not this particular manger’s fault of course, as this is not a power that he has. Ultimately if a change of culture is needed, the power is owned by the C-Suite.
Often times, I struggled to work with another department due to the conflicts of interests and priorities. Our manager went on an discussion with the other department’s manager. Unfortunately there were no result. The two departments have a different goal, which is reflected in the difference of their KPIs. Someone somewhere should have used the unused power to set the common goal.
Remember, the people below your pay grade often are struggling with problems that can only be solved by you (without them realising).
Placing multiple stakeholders in one team will not work. All of them will have different interests and priorities which will cause a disruption to the team. There is a reason why a team should be composed of one, instead of many, product owner. Multiple stakeholders should get together before confusing the team and determine which goal is the most important one. When everything is important, nothing will ever be important.
For a team to jell properly, all of the team members must be 100% allocated to the team. One team member’s failure of commitment will lead to the whole team’s failure of commitment. The not-100% team member will also have multiple stakeholders, which will lead to previous paragraph’s problem.
A remote team would work if all of the team members are all self-motivated. Also consider not setting up a remote team if you don’t gain access to better talent pools. Of course, all of the above must be satisfied for the remote team to be successful.
A walking skeleton works well in various aspects of software development. Based on my experience, it would work in feature developments, deployment pipeline creations, or infrastructure migrations. Pretty much anything that you can think of. Creating a walking skeleton is about implementing the smallest possible amount of work to get all of the important elements in place, end-to-end, then moving all of those elements in parallel together. Slicing user stories vertically, prioritising the slices, and separating concerns are the key for a successful walking skeleton. Based on my experience, these practices have proven to be hard, if not requiring a mastery.
The tendency of a new requirement is a running skeleton with gold plated feet. I’ve also met stakeholders who believe that the skeleton legs must be perfected before you are developing its skull. Be more observant and raise your concerns when these happens, then break the requirement down rigorously. Blinded by the perfect vision, it is too easy for people to neglect the value of what we are trying to deliver in the first place. It is always amazing to see what seemingly incomplete is actually delivering values when you are slicing your requirements down correctly and let the skeleton walk.
Interesting thing to note, one of the success indicator is a constant change of priority. Your stakeholders will be a priority changing addict, so make sure that you don’t leave technical debts behind.
