Transformation from a successful engineer to engineering manager

One of the most difficult career transformations is the transformation from an individual contributor to becoming a manager. For lack of the better term, "Manager" is an often abused term, so I prefer the term "Leader". One of the benefits I have had in my career is that I have had the opportunity to work with several kinds of people and this played a huge part before I embarked on a personal goal to become a "Leader".

So you are an engineer, you already know all the technical details....how difficult would it be to become a "Engineering Manager/Leader". I thought it was easy, with a feeling of "may be I will face the consequences later". It's the classic "Risk vs Reward" Scenario. After a few weeks of being a manager, I said to myself ..... "Holy Guacamole...this is not just being a software engineer". I have to admit, I did some mistakes when I started...but the key is that I kept learning from my mistakes. Let me enlist the key lessons I learnt and challenges I faced during my transformation:

1. Learn to work with people: This sounds simple in principle, but it is actually the hardest part. You have to learn what stimulates your team and peers, what motivates them, what keeps them happy and what helps in minimizing conflict. You also have to really focus on how their contributions will drive better results. You always need to be their mentor and help in their decision making.
2. Think Strategically: One of the key challenges I faced was how not to think/act like an engineer. This is incredibly hard because you have to force yourself to think out-of-the-box. The ability to innately and critically challenge decisions, viewpoints, problem domains and handle ambiguous data is what differentiates a manager from an engineer. From a management perspective, you need to see what business transformation can be achieved from your role and gather the best data to make it happen, present it to the executive/leadership team, engage them in your vision and then execute.
3. Attend Relevant Meetings: A huge downside of being a manager/leader is you have to attend  a lot of meetings. An important lesson I learned is that I have to only attend the meetings that I can contribute or I learn something from. I also recommend you to not attend meetings without a "clear agenda" or "your role is not clear".
4. Remain Technically Relevant: You cannot keep coding(as much as you would like to), learn to live with it. I quickly learnt that my passion to code cannot exceed more than 20-30% of my time. I did Code Reviews, Design Analysis, Architecture etc but definitely learnt to gradually reduce my intense desire to code.Now that you are no longer coding on a regular basis, it is a challenge to remain technically relevant and keep up with new technologies. 
5. Find Excellent Mentors: An important ability for every manager to have is becoming a coach for his reports. But who coaches the managers? When you are an engineer, you have a senior engineer or an architect to look up-to? What about management....It is easy to say...look up your manager....he might be your best mentor....he might be not too. Seek out that leader in your company who can transform your thought process, help your decision making skills and give you tough love as you are working hard to prove yourself.

I can go on and on....but hopefully this gave folks an insight on what it takes to make the transformation. Since there is no clear definition of success criteria, all I can say is I have taken the leap and hope to have made a difference in my organizations and also the people around me.

Why startup?

A few years back I worked at an exciting new traffic visibility startup - Gigamon LLC. Gigamon had its shares of up and downs but had some smart engineers and decent products. Having worked at different sized companies like Motorola, Yahoo! and Blue Coat, I wanted to share the aspects you would see in a startup and should I say they should be the ground rules for judging a technology(software) startup:

1. No Rules: There are no strict rules in a startup and this green-field approach fosters creativity at the highest level. It is an essential premise for a startup to maintain its blazing speed of innovation.
2. Winning Culture: Everyone is focussed on their job but also to do things right by suppressing one's own ego. To influence change the right way , the employees must respect and trust each other. When things are not right, don't hesitate to question authority. Accountability at all levels promotes a winning culture
3. Minimal Processes and/or Documents: Enforcing too much process leads to what i call "Organizational Drag". Too little process which is typically the case for most startups can lead to "Company Chaos". "Do you need something on security certificates....ask someone in Team K" is usually the answer rather than "Look at this HOWTO doc". While this is good in a super small startups, it does not scale well as the startup grows more than 50 employees. A "healthy evolving process with quality documentation" is necessary for any startup to succeed and grow organically. The key term here is "Process Evolution". Why does a process need to evolve? Since companies adopt different strategies, scale differently, workflows once made need tuning, it is necessary for process and documentation to evolve. 
4. Visibility and Freedom: Everything you do is visible. People are more responsive for positive change and appreciate your input. If you mess up though, you cant hide. You have a new idea ? - "Prototype it and show it to your VP or CTO" and he/she may accept it willingly and incorporate into the company strategy. In a medium to large sized company...the question always is "Who are you?" and followed by ..." please setup a meeting after talking to the admin assistant."In startups , there are no barriers to developing new stuff. This freedom is needed for building a creative culture.
5. Excellent communication: The speed of development in a startup also hides an important underrated aspect of software development which is "hash it out" communication. In most cases, you respect your peers since they are incredibly smart and driven like you are and you want to hash out great ideas, communicate your thoughts and collaborate and implement it. You go to your peer's cube....whiteboard your discussions and boom ...go and implement the idea or tweak it as your team sees fit. This is done in minutes and hours rather than email chains, comments perusal in a wiki etc which may take days. Lack of communication can bring down even an innovative startup in terms of technology.

Lot more factors can have an effect on "What makes/ breaks a great startup? Stay tuned for more insights.

Let me know what you think your experiences are?

Thoughts on Agile adoption at work!

One of the hardest problems in life is to enforce others to embrace change which you believe in. I recently went to an excellent Agile Conference - RALLYON2012 and it opened my mind to the power of team-work, constant collaboration and breaking down barriers. I am entrusted with this unique responsibility of enforcing AGILE in our company and thought I share my experiences on what I have learned.

1. Everyone has a different notion of the term "AGILE" . Some people think its about faster delivery of features, some people think it is a "Slave-Driver" mechanism, some people think of it as "Open Dialogue Progress".  Lots of people ask me "What do I get by doing this Agile process?"
2. Some teams change and adapt to Agile concepts of Daily Scrum, Time-boxed Sprints/Iterations and Releases and Burn-down Charts well. Some teams resist it completely due to strong personalities who believe "AGILE" approach doesn't provide benefit.
3. Product Managers have to assess the market, analyze the Field input, propagate new ideas, push requirements to developers and myriad of other things and hence cannot be Product Owners in an "Agile" World due to the enormous amount of load a Product Owner truly has which is to "Accept" User Stories and Defects on a regular basis
4. You cannot do Agile without the right level of Metrics at a Team-Level and at Project-Level. You need a tools team which focuses on providing this data to the stakeholders or have an Agile Lifecycle Management Framework like Rally provide the necessary tools and apps for you. Any tool you buy needs to be customized based on Organizational needs.
5. Changing the Culture in a Company which uses the traditional "Waterfall" model is extremely hard and takes lot of time. Don't force a culture change to happen too fast. Let it happen gradually and it is important to bring new people who embrace the "Inspect and Adapt Culture".
6. You need to have a "Agile-Process" Police in the company to ensure folks are doing the right thing and making sure the ship is sailing smooth without any pirates.
7. Cross-Site Scrums are hard to work with and not as effective as scrums with everyone in the team locally.

One thing is crucial : Belief in change and continuous improvement is essential for a company or organization to be truly "AGILE".