Category: Management

Programmers are intelligent, problem solvers. If you can’t believe this then please move on, this is not a post for you. If you are managing a group of programmers then here are the things that you should concentrate on:  Remove Obstacles By obstacles, I mean real ones. Things like Hardware, A.C not working, improper lighting, noise, printer out of paper, furniture, wending machine, pending feedbacks occupies very expensive portion of a programmer’s brain. You need to free this up so that they con concentrate on job. If you land up in a job which involves managing a group of programmers then the first thing you should do is make sure that the environment is appropriate for working and all barriers to productivity has been taken care of or at the very least, the programmer don’t have to bother about them.  Maintain flow of work A large part of your effort should be spent on maintaining the flow of work for the programmer. By this I don’t mean signing more contracts! You need to make sure that when the programmer comes in to office every morning they know what needs to be accomplished today. The programmer needs to know the work queue that has been lined up so he can go full throttle and get things done.  Get them the information they need It’s not that programmers don’t have business acumen, it’s just that they are closed to any problems that cannot be solved by writing codes. If that doesn’t makes sense to you, then think about why certain things don’t appeal to you. Thus, save them from this anguish and get them the information they need to know about the application. Don’t send a business case and expect them to deliver a working product.  They are more interested in knowing what the application needs to do.   Don’t talk technical This is only for the non-techies who need to manage programmers. Talking to them about technical aspects is the surest way to loose your respect. In case you can’t resist then try being suggestive rather than authoritative. I don’t think that managers respect better managers with the same intensity as a programmer respects a better programmer. Thus if your suggestions are shallow then you will loose respect forever and moreover, if they have to implement your solution then they will end up hating you. Stay away from this and rather focus your energy on getting the first three points.  Feel free to add to the list – the world really needs one!

I was recently going through a very interesting White Paper about Organizational Structure written by Richard Kibble & Neal H. Kissel of Marakon Associates, which presents a very different notion about the parameters based on which a business should form its Organizational Structure. As per Kibble and Kissel, an enterprises’ structure defines its strategy rather than the other way round. Flexible organizational structures leads to flexible strategies and better Global/Local Structures Produce Better Global/Local Strategies. Thus, better organizational structures lead to better strategies being formed and implemented successfully. This is because organizational structures greatly affects a manager’s management style. Structure critically affects managers’ decisions and, in turn, influences their emergent strategies. Managers with unique talents emerge when the organizational structure allows them to refine and perfect their craft. Better structures provide the an ideal platform for grooming young talent; allowing them to interact with various organizational demands and scenarios, in turn, creating better managers. If you want to develop more managers who can manage for value, create a lot of opportunities for them to manage for value. Managers with unique talents for discovering and developing new customer groups – or creating and executing new strategies – don’t emerge by chance. They emerge because there’s an organizational structure in place that allows them – and challenges them – to refine and perfect their craft. In short, organizational structure greatly influences the way managers function and make decisions. Hence it should be always be designed to exploit the uniqueness of the business with regards to its markets, products and more importantly, its people. To sum it all, if you want to have a distinctive strategy to outperform the competition, you need have a distinctive structure!

Answer this: You are sitting in your cubicle when you overhear two of your colleagues discussing a design issue. You do not like one of the guys in that conversation as you think he is a bit stubborn know-it-all type.  You then realize that they are talking about implementing a fancy new component. You have infact tried to implement this same component in one of your previous projects and found out that it makes the whole system unstable. Your last project nearly got cancelled becuase of the delays due to instability of that component but you managed at last to find a work-around for that problem. Will you still getup from your cubicle to share what you know ? Now answer this: You consider yourself to be a great programmer. Presently you are assigned to a project and you came across a fancy new component that could cut the development time by 10%. You are boasting about your great find to one of your colleagues, when he tells you that a guy in the next cubicle has worked on this earlier and there were some issues. What would you do – will you ask for help? There are extremely high chances that you have found it to be difficult to say “yes” to both these scenarios. As easy as the answers may seem, learning is often jeopardized by “Ego” and “Why-should-I?” syndrome. There are two important conditions for learning: Be a Teacher - Help others even when you are not asked for it  By teaching, I mean voluntary sharing of knowledge. No body knows everything about anything. If you share knowledge with others, then other will share knowledge with you. Thus, both of you will be more knowledgeable in the end and learn much more than what you would have learned individually. Don’t consider yourself to be a gift to mankind and make people come begging for your attention. Be a student – Be willing to seek out and accept help Sounds silly as it is but people love to reinvent the wheel and sometimes, they end up making square wheels on right when a perfectly rounded wheel is already there in the left. You have to learn to ask for help and have the humility and modesty to accept it. The student attitude is precondition if you really are interested in learning anything.

I have often seen people struggling with their business plan. I have a bit unconventional take on the subject. May be, because it has worked well for me till now. So here is what I sugget: A business plan does help. However a business plan should be proportionate with the size of investment you are making or seeking. So, if you are starting small and testing the waters, I will suggest you to have a “paper napkin business plan”. A plan which reminds you of – Your target audience,  Your product range and  Highlight the reasons why someone will buy the product / service from you. And, how will you achieve this? I feel that this can be a mini-strategy document which will help you and these three things must be “thought upon” before venturing into anything. You shall also put down in that paper – Your cash-flow statement (Expected revenues & expenses – both pessimistically an optimistically). You can use this to verify if you are on the right path or not? Your sales pitch! This is very important. If you are not convinced from your own sales pitch, no-one will be! Try to verify your sales pitch with friends you trust and take their feedback. Risks to your business and how you will mitigate them. Possible sources of acquiring business and how you want to prioritize and execute them. Possible sources of funds, if you really need them at one point of time. Some time bound goals! That’s it!   I think one can kick start a business from this “paper napkin business plan”. You can comfortably make it while you chew upon your favorite sandwich in the coffee shop. Best of luck with your venture!  

Perhaps the first company on the planet to think about the effects on employee turnover was the Ford Motor Company. Early 1900s were a turbulent time and employee turnover was killing the company. At around $2.25 a day, each worker was expected to work for around 9 hours. The attrition rate was nearly 300% and they had to hire 52000 employees to maintain a steady workforce of 14000 on the assembly line. It was then Henry Ford, took the unprecedented step of doubling the wage from $2.25 to $5 a day. The wage rate increase was not just about giving more money but it was a sort of first ever profit sharing plan. Working overtime is dangerous, I feel work related stress may be the #1 reason of attrition is software companies and meaningless overtime is the #1 cause of stress. However, still it’s not very hard to find instances of scheduled overtime when the project plan deliberately requires the team members to slog more-than-required hours each day on the project. Here is what you should know about overtime: 1. Programming is a mental work. The more time you spend doing it, the more tired you become. The more fatigued you are, the lesser you will be to concentrate. As the concentration down, the more bugs the system will contain. The more bugs the system contain, more money will be spent fixing it. So, the project will end up costing more. 2. People have a life outside work too. They talk to friends, pay their bills, eat out, do their laundry, sleep and do host of other things when they are not working. The more time they spend in office, the more overlap you will notice between their work life and social life. Now, you surely want people to keep out their social lives when they come for work, but at the same time you want them to work longer. That’s an amazing contradiction. 3. It’s not unheard of that top executives or entrepreneurs spend 80 hours work week. However, there is an important difference between motivations of executives and programmers. As expectancy theory states, there should be a positive correlation between effort (hours spent) and performance (output) and moreover, improved performance should lead to desirable reward.  So, although long hours of work will not stress the executive because they can link effort with rewards, but if the people in production workforce cannot find that link, overwork will simply stress them more. So, if you want to encourage voluntary overtime, then the employees must feel that it will reward them in desirable ways.  4. Finally, overtime reduces employment. If 4 people are doing 2 hours of overtime every day, it means they are doing one extra person’s job. Given the point is made about more defects and social life, there is no point in saving that cost of one more person because you are not saving it anyway.

Its rather a practice that you will find in most of the organizations. This is a form of management in which you just hit a developer with a command and then run away without looking back at what the consequences of the decision has been. Normally senior managers are too busy to micro-manage every employee and that’s good. It’s hard to know or remember the details of every project or what every employee is doing specially in scenarios where you have hundreds of developers doing lot of different projects of varying sizes. Then, all of a sudden something changes and you stop by at the developer’s cubicle and start a discussion about whatever work they are doing. You get into micro level detail of a project which you were completely unaware of approximately 10 minutes earlier. 3 minutes into the discussion, you find yourself completing sentences for the developer. Fascinatingly, within 5 minutes (sometimes 2), you presume that you know all about that given task or project and then give your verdict of what needs to be done and by when. The developer simply have to follow that without questioning. Why is this so bad? 1. The manager ventured into the project for reasons that are important to him rather than project itself. So, any decision taken will be biased towards their own interest. 2. Are you a trained Programmer ? Designer ? Database architect ? Project manager ? If not, you need to recognize your limitations and be aware of the fact that your decision will cause unwanted consequences. You might even don’t understand what’s involved in getting that piece of work done. 3. You are telling the developers that they are not smart enough, which in the long term will have negative effects. Pygmalion effect kicks in and the motivation goes down. 4. The developer gets a false perception from that point onwards, that you are controlling or watching the project. They will avoid taking decisions (because they feel that you will change it later!) while you are too busy with your actual job to follow-up with that project. The project will tail-spin and you will end up blaming the developer. So what do to? The fact from the other side of the table is that you definitely have been tipped-off  or something has caught your attention or fancy, for which you are deciding to take the matters in your own hands. You don’t want to do this but it seems you have no other choice. Here is what you can do: 1. Try to empathize with the employee and understand the conditions under which they are working. 2. Try adopting a consultative approach rather than a dictatorial approach. Help the employee arrive at the decision rather than making it for them. 3. Make sure you communicate the parameters you are considering while making the decision. This will set the right context when the person faces the same situation next time. 4. Communicate the degree of your involvement. Make sure that you tell the employee exactly what you are expecting and when will you monitor the progress again. 5. Follow-up your decisions, to see if it worked. If it has, give the employee the credit for making the right decision. 6. Avoid on-the-spot decisions when you are not sure, involve people who can give you broader perspective on what’s involved.