An opportunity to manage an existing software development team opened up in another city. Due to personal reasons, I cannot make the move. However, it triggered me to think what I should do if I am asked to take a lead on a new development team.

Leading an existing team is absolutely harder than building a new team up from scratch. The big difference is the trust between you and your teammates basically doesn’t exist at all. Nor does the trust between you and your partners from sales, service, technical support and other IT teams like analysts, testing and deployment.

All you can build upon is the chemistry between you and your hiring manager. He/she must have some deep confidence in you otherwise he/she won’t hire you to do the job. However, if that trust is built upon the first impression established through reading your resume and briefly talking to you in the interview, it can turn sour pretty quickly if things are not going on well. You are also facing the risk of losing your hiring manager suddenly and completely due to some reorganization, which is common in big enterprises.

I have witnessed a dozen or so new managers come and go leaving no trace. This is definitely dangerous water even for experienced navigators. Don’t imagine you will quickly shine as much as you did in the old familiar post. We all have to realize that our current success is built upon years of hard works and good relationships we established over a long period of time.

So, what will I do if I have to take the hat as the manager of a new team? How to secure the success of the new team? I will do it in three phrases.

Phrase 1: Learn and Understand

The important thing to keep in mind is that things are different! All dev teams are different in three perspectives: People, Process and Technologies.

People is the most important factor in the equation. There are three groups of people critical to get my job done. My boss/manager, my peers and my team mates. They are EQUALLY important. Yes, my boss can hire and fire me. No doubt, he/she is important. But, my peers, the managers of the analysts team, the QA team, the deployment team, the sales, marketing, service, technical support, hosting center, network engineering, other applications teams we need to integrate with, can also determine if my day will end up with smooth humming or frustrating yelling. And my team mates, they are the key performers. There is not much one people can achieve but for a team, there is no limits. By the way, my team mates are more familiar with the product, the process and the technologies than I do. They are the residents and I am the new comer.

There are many things to be understood about people. I will start with understanding their motives (what makes them come to work everyday) and their priorities (career, family, or self-realization, etc.) first. Then, how do them prefer to communicate, verbally (face to face/phone) or written (email, messaging, etc.) and what’s their communication style, casual or formal. For my team mates, I will go deeper. I would like to understand their strengths. One of my former bosses asked me to take a test of StrengthFinder 2.0 to discover the 5 strengths I have. I found that useful both to me and him. It won’t hurt to get up close and personal like knowing the educational background, the families, kids’ names and birthday, favorite sports team, etc. All those will set the great foundation of strong future relationships.

To understand the Process, I will follow through the application life cycles, from requirement, development, test to deployment, operation and optimize. Along this cycle, I will understand which team is involved, who is the head of that team, what tool is used, who maintain that tool, where are the documents, how products (new build) goes from one step to the next. There may be some vertical processes like budgeting, security, availability, capacity, service continuity (disaster recovery) to be understood.

One thing worth taking note is the current stage of the product. Managing a product that has never been released to Production and a well established Product in maintenance mode is fundamentally different.

As a development manager, the technologies details are not as important as the people and the process. So, I won’t drill down into all the nuts and bolts of the application. But, I must know all the business functions of the product, all the internal modules, their relationship, who the domain expert for each module is and all the external touch points.

Those above are all basic homework for a new development manager. Besides that, I will specifically understand the following:

  • Goals/Expectations: What to achieve in what time frame?
  • Challenges/Problems: What are the problematic areas? What are people constantly complaining about? What make the developers’ life miserable? Where are the mines and traps?
  • Image: How do my boss and partners see my team? If negatively, why?

This phrase may take several weeks to several months depending on how big the team and how complicate the process and organizational structure is. I will definitely have a talk with my new boss to get his/her agreement first. I will refrain from making any big changes in this period. Maintaining the “business as usual” status will be the best.

If the team or the product is in bad shape before I take the lead, this period may post a challenge. I may feel a lot of pressures to make quick moves to show some improvements. Then, this phrase must be shorten or may be combined with the second phrase.

Phrase 2: Build Trust

I strongly believe that productive works can only be produced by good team work. Good team work comes out of Trust. Lacking of trust will end up with all the internal barriers, unnecessary power struggles, finger pointing and inefficient communications.

But, as I realized already, a new development manager doesn’t enjoy the luxury of trust in the new poison. So, the next logical thing to work on is to build up trust.

First thing to do is to show people I really care. Reaching out to everybody in Phrase 1 and trying to understand them is a positive message to demonstrate I care. I will take one step further to show people I care by communicating back to them about my understandings of their expectations, their priorities, and maybe their frustrations too. Along with that, I will show my intentions to work with them in finding the solutions.

Next step, I will demonstrate that I am trustworthy. I can deliver what I promise.

To do that, I will pick the lowest hanging fruit with the highest priority. There is a simple formula to identify that specific area, Visibility = Business Value X Impact / Previous Performance. That means this area delivers enormous value to our customer, has significant impact not only to our customer’s experience but also to our partners’ performance, but previously the team either neglected or did a lousy job. Improvement in this area will have the biggest visibility and can help turning around the negative image of my team.

Once this area is identified, I will do the following:

  • Define the goal

Based on the understanding of the expectations, I will set the short term and the long term goal for this area. This goal must be S.M.A.R.T. (Specific, Measurable, Achievable, Realistic and Time-bound). More details about goal-setting can be found in a previous blog of mine.

  • Establish the measurements

Measurement is always the first step to achieve a goal, which must be measurable. Without the measurement, I cannot prove to anybody that our team makes some progress in this area towards the predefined goal.

The measurement should be Key Performance Indicators for this area. For example, for availability, it should be percentage of system availability, for development efficiency, it should be number of features/bug fixes in each release, for problem management, it should be number of production issues, etc.

The measurements must be published periodically, every month, every three months or every release. It should be distributed to all the concerned parties, not limited to IT department. The more external pressure, the more motivations to improve the measurements towards the goal.

All the measurements come with some management costs. So, I will prefer automatic measurements coming out of some tools or software programs. That will guarantee the objectiveness of the measurement and also cut the management costs.

  • Find the path

Goals set. Measurements published. Baseline established. Expectations sky-high. Pressures piled up. How to deliver?

I can drill upon my previous experiences and my technology know-how. But, that won’t be enough and won’t be efficient.

The key here is to release the creative talents of my teammates. It’s not about myself. It’s always about the team. It’s about establishing the new image of the team.

They know the system better than I do. They know the processes better than I do. They already know how to fix the problems! From my years of experience in IT industry, I can safely bet my money on it that somebody in the team already knows where the problem is and how to fix it. They are either not willing to bring up their ideas or they haven’t been giving the opportunity to express themselves.

I will setup several brainstorm sessions and a lot of one-on-one conversations with all my teammates to find out the right path to achieve the goal.

It’s very important that the entire team will feel he/she is involved in defining the path, the solution. It will be their personal success too if we succeed as a team. Any bright solution will fall apart badly without the whole-hearted support from the team. There will be different ideas and maybe fierce debates. People with lower voice volume may feel left out or rejected. It’s my responsibility to make sure everybody feel their voice is heard and seriously considered. To broker such a consensus is a true challenge of my leadership.

Eventually, we will have a plan, a roadmap to achieve the goal. I will have one or two backup plans in case the first one didn’t work out. I will communicate the plan(s) out to all the stakeholders to get their buy-in.

  • Improve iteratively

I am not a believer of luck. All the achievements are results of continuous hard works. So, I will never expect to achieve the high-shooting goal in short period of time. That’s cheating. I will break down the long term goal into small achievable steps. Each is just a hand’s reach from the previous one.

I will work with my teammates to carry out the plan we determined. Things may go wrong. We may have to put in some long hours. So be it.

But, I won’t stick to the plan without flexibility. A plan is just a plan, a reference and a guide. I will periodically measure our progress to see if we are on the right track towards the goal or we are heading the wrong direction. As a team, we will constantly revisit the plan according to our progresses and modify the plan if necessary.

If we fail to achieve intermediate goal, we will admit honestly to the stakeholders. Give them our honest understandings of the reasons for the failure and the remedy plans. I will always remember building trust is more important than actually achieving the goal. I won’t risk losing the trust to cover up a mistake.

I believe we as a team can make significant difference by focusing on one specific area and by go through goal and measurement setting, path finding and iterative improvements.

Delivering what we promise to our partners constantly will build up the trust level. In the process of delivering, I will also build up the trust among the team. As a team, we can work together to deliver some outstanding results. That positive feedback is essential to the team-building effort.

Phrase 3: Continuous Improvement

After the initial success and the sense of establishment, I will move forward to make some adjustments that have long lasting results.

I believe the impressive Productivity come from good Practices. Good Practices come from good Processes. Good Processes come from the good Cultures.

If I would like to get some short term achievements, I will focus on Practices. If I would like to establish some long-lasting results, I will focus on changing the Cultures and Processes.

I have written some blogs about the ideal cultures for a development organization including goal-oriented, innovation and humanism. I will add continuous improvement to the equation. Continuously improvement means never being satisfied at the current status and always thinking of how to make further improvements to get better results. Time goes by. Change is constant. Any good design or smart policies will soon be obsolete. Contemplating on the previous successes leads to future failures for certain. Only team seeking for continuous improvement can continuously stay current and relevant.

The ideal cultures can only be cultivated by establishing the aligning processes and policies. For a development team, the processes determine our everyday activities e.g. coding, source control, deployment, testing, production support, performance tuning, capacity planning, etc. In my experience, the ineffective and inefficient processes attribute to most of the problems of the development teams.

There is no one recipe for all the development teams. The industry standards, such as ITIL, PMP, RUP or Agile, can be used as references. But each development manager must determine the right processes for the development team according to the size of the team, the mix of the team members, the available skill sets, the external requirements, the available toolsets, etc. Establishing the right processes is another delivery iteration requiring goal setting, path finding and continuous improvements.

Besides achieving the external goals for the business, I will put people development at the same importance. The output of the team is the sum of the output of the individuals in the team. Developing my team members is the most efficient way to improve the productivity of the team. But, more importantly, helping other people achieving their life goals is the most rewarding thing I can think of.

In a team I worked before, all the team members were required to attend an educational course of “The 7 habits”. The course was based on Steven Covey’s best seller book, “The 7 habits of the most effective people”. I personally benefit tremendously from that book. I will encourage my team member to either read the book or attend that course.

I will start with understanding the career goals of my team mates and help them achieve their goals. I will help each of my team members to build a career development plan and assist them to achieve their career goals with their every day works. The best way to achieve that is by empowering them. They should gradually cultivate the capabilities to make independent decisions in the areas they are responsible for and I will make sure those areas expand as their capabilities grow. Eventually, I would like to see one or more of my teammates can fully take over my job with the same effectiveness and efficiency. That will be the celebration time for me and the time for me to move on to new challenges.

Leading an unfamiliar team is no doubt a challenge for anybody. But, it can also be rewarding. The uncertainty and the new challenges are the things that make the experience exciting and worth expecting. I am confident that I can make a difference by going through steps of understanding, building trust and continuous improvements. I am looking forward for future opportunities to put through those ideas into actions. And opportunity only favors prepared minds.