Tuesday, 25 September 2012

Project Manager, Business Users - Technology

How much technology a project manager should know? Is it just enough to know what's happenning in the team? Or more in the level of Solution Architet? Again there are different perspectives and variations. Let's consider a practical scenario and we'll see how each person in different roles act.

Let's say there happend to be a production problem in the middle of the night (if you are in the pub drinking during that time, don't take the call :) ) (say around 2 am, I like this time because this is the time I get calls) and it is serious issue and needs immediate attention. The below are the possible things each role can do if they get a call.

Q. What a developer can do?
A. A developer can login to the server, check logs and spends time understading what could have happend. Once problem is understood, he/she can see if this problem can be fixed remotely (assuming at 2 am you're at home doing remote login). If problem cannot be fixed from home or brain not responding, he/she convinces user who called by telling them that they can only fix at office hours.  

Q. What a senior developer can do?
A. Whatever a developer will do + he/she will think what could've caused the problem and how to fix it in terms of design. Also how to permanently eliminate this error in near future.

Q. What a solution architect can do?
A. Whatever a senior developer can do + he/she thinks of a mitigation strategy to eliminate this kind of errors in the midnight, and thinks about a plan and process on how to provide permanent solution to avoid this error and many other errors relavant to this error in terms of architecture etc.

Q. What a project manager can do?
A. He/She immediately calls any one from above 3.

This is what happens in most of the companies I've worked. A project manager's duty is go look after project in terms of cost, estimations (team lead help needed in this area), task allocation. And each person in team answerable to project manager.

I know a manager many years back. In order to explain problem and solution we applied to the problem, we needed to teach her programming language we used. For example, if there was a problem, say a NullPointerException, we added null check to fix it, if we say there was an exception and we added condition to avoid it, she used to ask us, what is exception? what is null? etc questions. Quite irritating, but she is a manager. So we gave her a Java crash course in 5 minutes to her and explained the issue in detail. Man, she learned so much technology in crash courses almost became solution architect theoritically.

Putting bias aside, a project manager should have 70% management skill and 30% technology skill. That's why I always like to work under Solution Architect's supervision rather than pure management type people.

I also don't like to interact with business users, the moment we try to explain why certain things cannot be done with certain technologies (like controlling their browser settings from our servers, weird!!) they stop the discussion complaining 'its too technical'.

Because of all these experiences, I decided to stick to technical career path eventhough I am getting PMP training offers at good discounted price. I prefer to manager servers rather than managing people. At least, servers will follow your orders!!

Finally, a joke I remember about managers. Here it is:

A man goes into a pet shop to buy a parrot. The shop owner points to three identical looking parrots on a perch and says, "the parrot on the left costs 500 dollars".

 "Why does the parrot cost so much," asks the man.

 The shop owner says, "well, the parrot knows how to use a computer".

 The man then asks about the next parrot to be told that this one costs 1,000 dollars because it can do everything the other parrot can do plus it knows how to use the UNIX operating system.

 Naturally, the increasingly startled man asks about the third parrot to be told that it costs 2,000 dollars.

Needless to say this begs the question, "What can it do?"

 To which the shop owner replies, "to be honest I have never seen it do a thing, but the other two call him boss!"

(copied from http://www.workjoke.com/managers-jokes.html)

Tuesday, 4 September 2012

How to become 'Solution Architect'

Every Java developer's aim (mostly) is to become 'Solution Architect' because of the glamour this word has (another motivating factor is decent pay). I am also a Java developer and sometimes I try to relate my experience and knowledge to assess where I stand. Definitely long way to go to become Solution Architect. I have few thoughts on how to become Solution Architect. I am sharing few of them.

Before that, I want to make it clear what is Solution Architect in my own terms. Who is Solution Architect:

- A developer who is ready to code.
- A designer who is ready to draw UML diagrams.
- A coordinator who talks to project stakeholders to get requirements (functional & non-functional).
- A translator who translates business needs to technical requirements and vice versa.
- An estimator who can estimate project's cost and man days.
- A troubleshooter who can debug a problem and provides mitigating strategy (or solution).
- A process improver who suggests ways to improve process and productivity.
- A mentor who is ready to share his knowlege with his team and enlightens them.
- A person who have deep knowledge and experience in one technology and comfortable knowledge on other technolgoies.
- A good presenter with good presentational skills.
- Finally someone who takes blame if things go worse.

Ofcourse above criteria is very vague and differs from organization to organization. Well, how one person can develop so many qualities. I read somewhere that to become Solution Architect the best way is to act like one. So one developer thinks he/she is a Solution Architect what will happen?

 In positive terms, the thinking process changes, its totally a different perspective. As a saying goes... "A developer is concerned with what will happen when user clicks a button, an Architect is concerned with what will happen when 10,000 users click a button."

If you assign a task to a developer all his focus is only on coding, he will start coding right infront you and a hurry to deliver the code. However if you think an architect, instead of opening up your IDE you will surely ask questions.

Questions could be related to funtionality, maintenance, design, security and performance etc. Also you try to give best refactored code with patterns used whenever applicable. This is the difference. The best way to become Solution Architect is to think like one. Give best in what ever you do. Think of all aspects of a system not just code.

Since architecture is the basis for project and business, it should have solid foundation. If architecture is not scalable the risk is severe because rest of the system components are going to rely on the architecture. So the architect should fully undetstand stakeholder needs and try to leverage their needs with cost and timeline.

Becoming architect is not just a week's work and we cannot become architects by sitting in caves or by attending trainings. Its a continuous process. We constantly need to update our knowledge beyond our skill areas. We need to show great enthusiams to solve problems and we must have good patience with positive attitude. I always believe that Solution Architct is a role rather than a designation.

For all of the developers who wants to become architects, Good luck and bon voyage!