Seven habits of highly defective co-worker (2) – Mr Know-It-All
Mr Know-It-All (KIA) is not exactly my co-worker. He used to work in another department of my ex-company. During my time in the ex-company, I seldom had the chance to work with him luckily. But I did hear a lot of bad things about Mr KIA, particularly about his boastfulness.
After I set-up my present company, I had taken up a few ad-hoc projects to supplement the revenue of the company. One of my customers, Company Y, is a company that is in the same sector as my ex-company. Apparently, Mr KIA had joined Company Y, and unfortunately is the highest ranking technical person of this company.
My first assignment with Company Y was to enhanced one of their existing software within a short time frame. I was then engaged by their AGM, and this AGM ordered Mr KIA to assist me by providing the relevant specifications. Mr KIA claimed to know the system very well, but eventually the specifications that he gave me was full of errors. Nevermind, I fully expected that to happen and I managed to deliver the required tasks despite of the obstacles.
One thing I wasn’t quite happy about Mr KIA was that, he persistently claimed that the tasks assigned to me was very simple and he could have easily done it, just that he was too busy with other works. However, from my many years of experiences, I could safely gauge that the tasks had a certain level of difficulties, even to an experienced software developer. Furthermore, Mr KIA is a hardware person with very little software knowledge and experience. I was highly skeptical that he could even understand the design of the system in the first place, let alone implementing any enhancements. Moreover, the assignment was already lagging behind their promised schedule and absolutely nothing was being done. If it was so easy as claimed by Mr KIA, shouldn’t he put aside other tasks and delivered this assignment first?
Anyway, when I delivered the system, the AGM requested that I port the software over to one of their existing PC. However, I do not know about the environment settings required for the software to run. My development work was done on a laptop supplied by the AGM, with all the required environment settings preset by Mr KIA. So obviously, I would need to ask Mr KIA about the required environment settings. To my dismay, Mr KIA ignored my requests, claiming he was very busy. So eventually, I had to trial and error, meddle with the registries, run into a lot of errors, just to get the software working on the designated PC, all because Mr KIA was “too busy” to tell me the required environment settings.
In the end, I spent one whole day in their office to settle the configuration and environment settings all by myself. At the end of the day, when the AGM came to ask about the progress, Mr KIA suddenly turned very helpful and asked me whether I need help, in front of the AGM.
Furthermore, during the few meetings I had with Company Y, whenever the AGM asked for my opinions, Mr KIA would try to interrupt and eagerly offered his opinions before I could say anything. I figured out that Mr KIA perhaps felt a bit threatened by my existence, and thus tried to make things difficult for me and at the same time hope to impress the AGM. But I was just an external consultant, not a colleague in direct competition with him. Why should he feel threatened by me? One explanation would be, it was just his nature to try to impress people at all cost.
My subsequent dealings with Company Y had further unpleasant experiences with Mr KIA. But that was another long story.
Labels: Co-workers, Working life
Customized or COTS software ?
Some of my customers don’t quite understand the difference between customized software and Commercial-Off-The-Shelf (COTS) software.
Customized software is a software that is built to cater to a particular customer’s needs. Normally, the process involved would be requirements gathering / analysis, software/system design, coding, integration, testing, deployment, etc. Due to the details of customization, customized software usually cannot be transferred between projects, though some components may be reused. Such project would normally be charged according to the number of man-hours / man-months. For example, let say a certain customized software project required two engineers to work on it for a total of three months, the number of man-months required would be six. If the total cost of one engineer is S$4000 per month, the cost of the project would be S$24,000.
On the other hand, COTS software is developed without the intention to meet specific customer’s needs. Such software is normally built to fulfill the basic needs of majority of the customers in the target sector. Thus, the price of COTS software is normally much lower than customized software, except for some very specialized COTS software. The downside is, you will have to accept whatever the COTS software provides you. Some example of COTS software would be Microsoft Office, Adobe Photoshop, etc.
Sadly, some customers that I met want the best of both worlds. They want the software to be customized to their specific needs (with functionalities that are normally not present in similar category of software), yet compare the price with COTS software like Microsoft Office when we talk about the customization charges. In cases like this, I would have to patiently and painstakingly explain to them the complexity and effort involved in implementing the customization they required, and the man-day charges of my company.
Customers are not always right. Sometimes, they also need to be educated.
Labels: Miscellaneous, Software
Apply OOP techniques in answering difficult questions from customers
Some of my customers liked to ask questions beyond the scope of my product, especially when they found out that this is my own company. However, not all questions can be easily answered without exercising a bit of selective truths. Well, in object-oriented programming we called this “Data Abstraction”:
Simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
Below are some of the difficult questions and its corresponding abstractions:
***************************************************************
Question: How many people are there in your company ?
Answer: Currently there are five of us, plus some temp staffs.
Abstraction : In the “MyCompany” class, there is 1 director and 3 other passive shareholders. To simplify things, the class only exposed the attribute “people”, which is the total number of active and passive headcounts, to outsiders. Hmm…did I mention my pet ?
Question: How many customers from my sector are using your products ?
Answer: (Insert a respectable yet reasonable number here)
Abstraction: In the “MyCompany” class, there are 3 private attributes concerning number of customers: “total customers”, “potential customers” and “existing customers”. However, we only provide accessor method for the attribute “total customers”, which is the sum of “existing customers” and “potential customers” multiply by a random constant.
Question: How long has this product been in the market ?
Answer: Around 2 years.
Abstraction: Well, the first version launched 2 years ago is far inferior to the current latest version. But the truth is, it is really in the market for around 2 years.
****************************************************************
Well, it would be rather suicidal to reveal to customers that this is an OMO (One-Man-Operation) company. They would most probably not give you the chance, and instead opt for an inferior product from a bigger company. Or in some case, they would try to “eat” you by requesting a lot more features while reducing the price.
As for question two, nobody wants to be the pioneer to try out a new product, even though it had already proven working in some other sectors.
I guess sometimes in life we need to be selective in what to say and what not to say, even though we may not like it, as long as we are not hurting anyone in the process. Applying “data abstraction” techniques is just one way of doing that.
Labels: Customer Service, Entrepreneurship, My Adventure in Uncharted Waters
Seven habits of highly defective co-workers (1) - Ang moh accent VP
I remembered bumping into my ex-VP at the pantry, when I was still working in my ex-company. Apparently, my ex-VP tried to be friendly by striking up a conversation with me.
“Hello Nk, jiak ba buay (hokkien: have you eating already) ?”
I looked at him blankly. I was trying to figure out which was more absurd: Speaking hokkien in a fake ang moh accent, or acting friendly with someone you don’t even know his name ?
“Oh, you are Nk or CS ?” my ex-VP somehow sensed that he got my name wrong.
“Neither. I’m XXX.”
The conversation ended abruptly.
Lesson 1: You don’t have to call the name of the person in order to act friendly. It may just bring about unnecessary embarassment.
Lesson 2: If you are a low-profile engineer, try not to go pantry too often.
Labels: Co-workers, Working life
In Business, you gain some, you lose some
I rejected a business recently. A client called me in regards to a quotation that we sent to him two years ago. It was some kind of networking and integration project. It wasn’t our company’s core business and frankly speaking we do not really have the expertise to undertake the project. However two years ago, our business was so bad that we were desperate enough to take up whatever projects that came to us. And thus, during that time, we issued a quotation to that client, with the intention of outsourcing the project to some other company if we happened to get it. Surprisingly, the client did not proceed with the project back then, only to come back to us two years later. I hesitated before I rejected the project. I am thinking of whether I should refer the client to other companies but in the end I didn’t, because I did not know those companies well enough that I can be sure they will do a good job.
Ever since I was at the helm of the company, I had been very careful and selective on the projects that my company undertakes. My approach towards business is obviously very different from my ex-partner K in the sense that K was more concerned about earning as much revenue as possible, while I always think of the long-term growth of the company as my top priority. To me, building up the core capabilities of the company is much more important than earning revenue through some ad-hoc projects, although sometimes revenues from some ad-hoc projects can be too attractive to reject.
Coincidentally, I have another rather lucrative software project coming up, but I still haven’t decided whether to take up because I have some considerations that are holding me back. Firstly, the level of complexity of the project is extremely high. Secondly, the project isn’t something that I liked to do. I may sound idealistic but one of the motivations behind setting up my own company is to be able to do things that I enjoyed, and create products that I really wanted to create. However, the potential revenue from this project would enable me to expand the company quickly.
I believe in business, there bounds to have some level of compromise between idealogy and pragmatism. Sometimes you choose to hold on to your ideals. Sometimes you need to do stuffs that you may not like, yet is good for the company. I am still in search of this balance. In business, you gain some, you lose some. Losing some deals is just part and parcel of the game, but losing your ideals can be disastrous.
Labels: Entrepreneurship, My Adventure in Uncharted Waters
“Interesting” people encountered during my entrepreneurship venture
Ever since I ventured into the uncharted waters, I had encountered a lot of “interesting” people. Much more compared to the days when I was still a software/R&D engineer. The interesting part is, not only did I meet new people with interesting attitudes or characteristics, my existing friends and associates had also exhibited similarly interesting sides of them. I shall just categorize them to better illustrate their uniquely interesting traits:
1. The Advisors
This group of people have inborn advisors’ mentality. They are always eager to offer their advices, even if nobody requested for them. I had no problems with people giving me free advices on how to manage a company, although most of them do not have the adequate knowledge or experiences. Normally, I would just listen to them patiently.
However, some advisors are not contented with just giving advices. Sometimes, they would argue with you passionately and insist that you should implement what they suggested. That’s where I would get a little piss off. If these advisors really felt so strongly and passionately about something, maybe they should try to do something themselves. Instead, they prefer to sit in their own comfort zone and force people to heed their advices. 2. The Analysts
This group of people loves to analyze. Particularly, they love to analyze how you will eventually fail. They like to analyze your business model, your operational cost, your profit margin, your market sector, etc. And very often, they will reach the conclusion that your business / company cannot survive.
Again, I have nothing against people who gives me free analysis. However, this group of people should also realize that there is only so much that one can see from the outside. There are many other factors like the roadmap of the company, the changes/maturity of existing market, the R&D and technology management, new opportunities, new team members, etc. All these factors contribute to the success/failure of a company, and they are often not readily revealed to outsiders like the analysts group of people.
Sometimes I can’t help but to feel a bit bizarre about the actual thoughts of the analysts. Why is it that this group of people loves to analyze how you will fail? I sort of smelled some sour-grapes in them. Perhaps some people do not enjoy witnessing other people’s success, as it would remind them of their own lack of courage to pursue their dreams.
3. The Whiners
The whiners complain about almost everything. They attribute their reluctance in pursuing their dreams to lots of external factors, but fail to see that maybe the greatest factor of all is their own inabilities and fear. It’s easy to whine and point fingers, and perhaps it is self-comforting for this group of people to view themselves as victims of circumstances. But if you have the time to whine over and over again, you would probably be better off if you start to do something about it. Labels: Entrepreneurship
