This article is a continuation of my previous article:
Why your Software Company is failing inspite of “everything”
Engineering Management is one of the most important drivers of success for any software company. I have seen many…
Here are some notes from one of my prior experiences working in a small, self funded startup where we were able to achieve high productivity while keeping people happy:
Be objective while evaluating every direct report.
Very often our outlook is clouded by evaluations & judgements from others. Every person treats another based on how they are treated. I treated people fairly and objectively based on how they interacted with me.
I found that even people who were labelled was “lazy” or “unproductive” and “need to be fired” were very productive under my management as I treated them right. The CEO remarked that the team and some people have never been as productive as they were under my management.
Talk to each direct report from their perspective.
It lets you really hear what they truly feel and allows you to advise them effectively like a close friend rather than as a manager. This makes the person feel heard and they are able to step up as required.
When there are disagreements try to make the person see the other’s perspective.
The world is not black and white — there are just different perspectives. If you understand the other perspective, you could influence the other person by speaking from that point of view.
Never get upset at a person (especially in public)
Anger only makes the situation worse and the person unproductive. Remember that an upset person does a worse job.
Improve transparency by bringing the metrics and data upfront.
Have a TV display the sprint progress in the office. Team members can see what the root causes for issues were. This forces them to see issues by themselves and rectify it.
For example, a developer realized that all his issues were because he was not speaking with the subject matter expert (knowledge issue). Seeing the metric on the scrum board, he started to speak with the other developer even though they were not on speaking terms.
Modulate the behavior based on the other person’s mindset.
Some people like a formal one on one meeting in a room. Others like chats while going out to get lunch or while walking outside.
Fit the process to the company — don’t put a square peg in a round hole.
I had to customize the scrum process to fit the needs of the company which needed a sprint begin & end, but issues would keep coming in like in Kanban.
Create formal metrics to show progress or the lack of it.
Progress should not be driven by perception of people — it should come from hard numbers in the JIRA board.
Identify the real impediments affecting team velocity.
In one case, the problem was that we had a lot more developers than QA. We had to hire more QA because we could not test the feature or fix as fast as it could be developed.
Design a branching process based on the company needs.
We developed a completely different branching process & strategy than what I had ever seen yet for this company. It was based on the fact that no bug or feature would wait on any other at any stage.
Let the team focus on the work at hand and not distracted.
I was able to get significantly higher productivity because the team was allowed to focus on their work and there were no distractions in the work environment. This allowed them to complete work in time and with high quality.
Listen to all sides of the conversation and don’t take sides.
I would speak for PM in one meeting, and QA in another. I would speak for the developers in yet another meeting. This ensured that all parties considered me to be unbiased and I was able to move the team forward by evangelizing different perspectives based on the situation at hand.
Processes need to be modified based on the business model of the company.
How we run projects are determined by how the company gets its revenue. For example, a VC funded company with lots of cash developing a product would be run very differently from a self-funded company who creates new products from the revenue earned from contract based fixed cost projects.
It matters how you are perceived even by the least powerful person in the organization.
You will be surprised by how effectively you can be screwed sometimes by the least powerful person in the company. Don’t create one more person who hates you — your job is hard enough as it is!
Project Management & Scrum Skills
A good Engineering Manager is a go to person who can take the toughest projects by its horns and deliver outstanding results well within time and budget. They are able to do this because of their deep-rooted skills in understanding how to fully optimize the development process for maximum speed and agility while delivering a product of outstanding quality.
Many good managers have delivered projects which have been given up as impossible time and again. A very important reason for their success is that they face the problem head-on, well before the deadline rather than getting demoralized and “just doing the best they can and waiting to see what happens”.
The right time to worry about a deadline is months beforehand. Proactively digging down to the details, not losing heart and finding creative technology and process based solutions to meet it well before it becomes a larger problem is the way to tackle it. Ignoring the problem, does not make it go away — it just gets worse over time. There is always a way — if you choose to study the problem and thinkabout how to solve it.
How many of us actually spend days and nights just thinking about a problem and regurgitating it in our minds?
The usual approach I have seen most often is to try and find a solution right away, or in one or more meetings where people look at each other, fail and then give up on it. Most tough, real-world problems cannot be solved in this manner. This differentiates the exceptional managers and programmers from the others.
The superb candidate who can answer every question “immediately” maybe the wrong person for the job, because they are not used to thinking and really solving a hard problem to which they have no immediate answer.
Such people fold when facing real problems. It is the people who can take the problem, think about it, live with it, and eventually solve it after days, weeks or months who succeed in doing hard, complex projects.
People who get every answer from a book they have read also have the same problem. They have given up their problem-solving skills to others. When faced with a real-world issue, they also fold, until they can find someone or something who can give them the answer to the problem.
As the deadline nears, activity should be slowing down and people should get calmer and less stressed as they know that it will easily be met. It is not the job of the Engineer working on the “floor” to figure out a way to meet the deadline.
The Engineers job is to focus on the code and stabilize it, it is the manager’s job to step back, see what is happening and figure out a way to meet the deadline. Too often I have seen Engineering Managers panic at the last moment while team members are demoralized for weeks just before the deadline because everyone has given up on the fact that the deadline cannot be met.
I am a true believer in Agile development with a high emphasis on test driven development and unit tests. I have seen firsthand the positive effects of starting a project with TDD to begin with. I have also seen people take the quality of the product for granted, stop TDD and see everything fall apart.
Going for a scrum training does not prepare a manager to run an effective scrum organization. One can only learn true agile and scrum by having worked hands-on in a project run by great scrum masters. Only then does one truly understand how to run scrum properly.
Most organizations do not do scrum properly and hence fail. True Agile can only be learnt by practical experience in good Agile environments. I have observed extremely talented scrum masters running a dual offshore team with effortless ease moving the project forward with finesse.
A good Manager has the ability to identify and propose solutions for impediments during scrum retrospectives. I think one of the best articles which showcase the advantages of having an independent team with self-management skills, and explains how to build such a team is:
What Google Learned From Its Quest to Build the Perfect Team (Published 2016)
The Work Issue New research reveals surprising truths about why some work groups thrive and others falter. Credit…
What I liked the most about this article as opposed to many of the management books from Harvard Business Review is how they went about the “other way”, reverse engineering and studying the culture of the already successful teams.
One of the key learnings I can recommend is to separate bad apples from the good ones. The best way to destroy Engineering culture is to retain bad apples in the company who are B and C players — because A players work best with other A players. This is one of the secrets of hiring and retaining the best employees and having them contribute year after year on a long-term basis.
One of the important lessons I have learned is the need to allow developers to focus without distraction during the sprint. This is more important when the software being developed is more complex. I have observed in my own experience that the most successful software teams always had several things in common:
- Engineers stayed for years with the same company, gathering expertise.
- Engineers had a lot of time to focus on the code without constant interruptions in any form (manager, meetings, etc).
- A concentration of very high caliber engineers working in the same company.
- Engineers are trusted to do the right thing and there is no micro-management.
- Management with high EQ or deep understanding of engineering processes.
Sometimes it is necessary to write unit tests after the development has been stabilized in a sprint. It is also recommended that formal QA testing and the writing of test cases for that purpose is done after the development is completed. This allows the developers to focus on the work at hand, and reduces a significant amount of rework which could happen if the code changes a great deal before it gets stabilized.
Some of the best developers who do the most work in a project often produce significantly more code and change this code a lot before settling down to stabilize their work. It is to be noted that this advice should not be generalized and used for all cases. It depends on the complexity of the application being developed.
At the end of the day, what distinguishes a great Engineering Manager from others is when you look back at the organization you see growth instead of attrition. You see great people working together for years on an amazing product which has driven the growth and success of a company. You also get surprising calls 10 years after you worked with an engineer where she expresses gratitude for your mentorship. A good engineering manager builds lasting bridges with his mentees, rather than burning them.
I am a believer in the great power of thought. Any problem, no matter how impossible it seems to be, whether it is technical or managerial, at home or at work, can be solved by creative thinking and tenacity. Very often the best solutions come when you analyze a problem in solitude.
This is one of my favorite quotes from Steve Jobs:
“When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can oftentimes arrive at some very elegant and simple solutions. Most people just don’t put in the time or energy to get there. We believe that customers are smart, and want objects which are well thought through.”
Real problems are solved in a thoughtful manner, by confronting them headon, and without ignoring them, or “hoping” they will go away “somehow”. You have to live with the problem, actually think about it both consciously and subconsciously, and then arrive at the solution.
You have to train your brain to solve problems by itself and not rely on someone or something else as a crutch.
It is strange when the name of a company has the word “culture” and they work with people all over the world, and yet a manager there fires the only two non-white people in the entire department — everyone else still works there. This is a company which is perceived to be Democrat leaning — and they also fund the party of President Obama. The only fault of the people who were fired is that they were culturally different from the rest of the team.
Just paying some money to the right people or party, and having former presidents show up at company functions do not make you progressive.
A person from another culture or race is not “wrong”, “bad”, “lazy” or “needs to be changed”. They are who they are, and you need to accept them for who they are, especially if you are a growing company and desperately need good, new people. Many of the qualified people you find in the market may not be local candidates. Do not make the mistake of thinking that everyone is the same — everyone is actually, very, very different from each other.
If you think everyone is the same, and they think the same — that is your first mistake. Americans are different from Europeans are different from Asians. Even Asians from different countries in the same region maybe quite different from one another.
One of the most important skills for an Engineering Manager in today’s multi-cultural world is to recognize and work well with people from diverse cultures. When teams are very diverse, there needs to be a great deal of understanding, patience and coaching to get the team to work together effectively.
People from diverse cultures cannot simply be thrown together into a single team or teams and “just work”. It takes a very skilled manager to bring the team together and prevent chaos and misunderstanding. I have some outstanding experience working with teams of vastly different cultures all working together in the same project across time zones. I have been deeply influenced by this book:
The Culture Map: Breaking Through the Invisible Boundaries of Global Business
The Culture Map: Breaking Through the Invisible Boundaries of Global Business [Meyer, Erin] on Amazon.com. *FREE*…
Diversity of thought is very important to encourage in a good engineering culture. This is recognized as a key driver of improving productivity within the Microsoft Training when a new employee joins.
Many highly technical Engineering Managers make the mistake of trying to get everything done “their way” or to micro manage. This significantly reduces the collective intelligence of the team and produces negative results.
I believe that every person thinks differently, and every approach should be encouraged. Just because someone failed to get something working does not mean that the newbie may not be able to do it. Everyone has to be given a chance — all alternatives have to be fully explored. It is a good engineer who can say: “I’ve tried everything I can think of — let’s try something — anything else — which is different”.
This is one of the ways, we managed to fix a very difficult problem at midnight before a major release to a major company. The idea for the solution came from the quietest, least experienced member of the team.
Being Customer Centric
One of the most important skills to have is the ability to listen to a customer or a support manager and try to figure out a solution to the problems they share with you rather than be defensive, give excuses or confuse them with technical terminology.
Customers and Support people may often say things which are technically incorrect — it is just their way of trying to explain and fix the problem they are facing. It is the job of the Engineering Manager to understand their problem and try to find a creative solution to meet their needs. The most important thing is to take responsibility for the issue and meet it head-on rather than try to deflect it.
A good leader understands what to do when the company changes strategy. When company goals are discussed, in an executive meeting, they think about how and which processes may need to be changed to align the department with the new strategy.
For example, at one company, they changed their strategy to dig deeper into existing accounts and be a full solution provider — this directly translated into Engineering changes to ensure that we focus on quality so that existing customers are willing to spend more, and team structure modifications so that no plugin is “left behind” and abandoned as was happening.
The hardest part of leading Engineering is figuring out what to change when the company changes business strategy.
Another good example was when the executive management decided to support a non-industry standard version of a product, we decided that, if we are going ahead with the plan to use the solution “as-is”, QA will still need to test it out, determine the limits and ensure that it works as desired. This is another example of there being tangible, deliverables which need to be met by Engineering even if nobody explicitly points out that it needs to be done (as other executives are business focused and unfamiliar with technology and engineering processes).
A good leader is not defensive and takes on responsibility for her work. Technology and engineering process details should not be used to confuse other executives to win arguments. Sometimes, when non-technical issues are raised, Engineering needs to take on the leading role to figure out what the problem is — and how to fix it.
It is not the job of the support department or product management to figure out these technical details. Similarly, highly technical details of implementation may require technical architects to prioritize. PM may not always be able to prioritize the work of fixing some arcane multi-threading issue w.r.t something else in the backlog.
When in an executive meeting — other VPs may point out a lot of issues which may seem never ending and relentless. The VP of Engineering may have spent a week prioritizing all the customer issues into a single list (as in scrum), when the other VP may point out that the list needs to multi-dimensional as each plugin is equally important. In such conditions, most VPs get frustrated and defensive — this is a problem — this is trying to fit the market need to defined Engineering processes. It really should be the other way around as Steve Jobs has mentioned in a quote:
“You’ve got to start with the customer experience and work backwards to the technology, not the other way around”
We need to look at all the complaints from a perspective of requirements gathering. The perspective has to be: “They have told me about some issues, what can I do to meet their concerns and resolve them?”. This led to out of the box thinking, and on many of the cases we were able to save hundreds and thousands of dollars and tens of large customers — sometimes by not even changing the code!
You need to take the responsibility, walk the talk, and deliver results. Trust is earned by delivering results, not talk or title.
Continuous Improvement, driven by Metrics
Continuous process improvement is only possible when the correct metrics are used to track a process. Process design should be driven by what the customer is seeing rather than from the perspective of any specific department within the company.
If you just resolve a customer issue as a workaround and temporary fix, and the real issue is unresolved — the escalation should remain marked unresolved until a fix is actually applied to the software and released to GA. This is the right way of using metrics — if the customer sees X issues, the management also sees the same X issues. The validation for this is that perception is the same as reality.
On the other hand, if each escalation is taken as a help desk case and marked as “done” after temporary fixes are made, the metrics may show that issues are resolved fast, but call volume remains high as other customers report the same issue, and the number of unresolved, unfixed hidden issues increases.
So, we have a situation where reality is very different from the metrics reported to the company. This is why executives are often surprised at the end of the quarter when they get bad results while all along their metrics seemed to be fine. In a properly defined process which is unbiased, customer and support perception would be the same as reality.
Leadership & Team Building
It is very important to properly introduce yourself to the team, when you join or when a new employee joins your department. This is extremely important because when you/ they join a new company, nobody has any idea about who you are, or what you have done in the past.
It is very important to not only introduce yourself properly, but to also get to know each and every one of your direct reports and what they have accomplished for the company.
You should never join a new company and immediately start changing things to how you are accustomed to. You should always go through a phase of observation where you see how they do things, ask a lot of questions, wait, and see what works and what does not.
You don’t always have to change things. You only need to change that which does not work, and which clearly causes failures. If something unexpected to you works well, that should be taken as a learning rather than “changed for the sake of change”.
I think the best quote which reflects my philosophy towards the work output is from Steve Jobs:
“We have an environment where excellence is really expected. What’s really great is to be open when [the work] is not great. My best contribution is not settling for anything but really good stuff, in all the details. That’s my job — to make sure everything is great.”
Here are some ideas from my experience:
- You have to spend a significant amount of time “getting the right people on the bus”.
- Provide motivation to the team by leading from the front in all project activities.
- Provide motivation to the team by inspiring the team members continually to build world class software and to give their best, instead of just getting the work done.
- Constantly communicate with the team to gauge their morale — prevent attrition of good people before it happens.
- Ensure developers are adequately rested and nobody works long hours.
- Implement flex timing for team members so that they could work 8 hours only and come in late if they stayed late.
- Tell the team that it was ok to feel threatened when they see someone is better than they are. But, they need to accept this, overcome it and encourage such a person, rather than working against them.
- Be very transparent, straightforward, open and non-political, hence, the team is focused on getting great work done, more than office politics.
- Write effective annual employee reviews.
Your manager should be able to picture the personality of every member in the team after reading your annual review of a direct report.
- It is not the job of the employee to tell the manager what he accomplished in the past year. It is the duty of the manager to note down both the good and the bad, and put them in the review comments. This rewards the A-players and allows the company to recognize and coach B and C players.
I believe that people perform their best and are motivated the most when they are asked to do the best job they can do, rather than to just finish work as fast as they can.
“If they are working in an environment where excellence is expected, then they will do excellent work without anything but self-motivation. I’m talking about an environment in which excellence is noticed and respected and is in the culture. If you have that, you don’t have to tell people to do excellent work. They understand it from their surroundings” — Steve Jobs
I believe that people will go over and beyond when the manager really takes care of them, listens to them, and proactively works to create a healthy team culture. I believe it is important to delegate work and trust people to have a growing team.
Working with a multi-cultural team effectively is a very hard thing to accomplish which requires strong processes, exceptional cross cultural skills, patience and understanding.
One of the most important items to do when working with an offshore team is to have a good process in place for sharing information. In the early days, it used to be a shared status excel sheet, nowadays, we have project management software like TFS/ JIRA/ Asana for this purpose.
Use a tool like Asana to assign tasks to the offshore teams, and also setup offshore managers to ensure that assigned work got done within the expected timeline. This management structure has to be correctly defined.
Offshore teams should always be managed through their internal management structure. I have seen chaos happening when onsite people have tried to directly manage offshore developers bypassing the offshore management structure.
It is also important to ensure that more than the “normal” amount information is sent and received during each point of contact. This ensures that once the offshore team has left the office, communication they have sent is adequate for the onsite team to move ahead and vice-versa.
The best example of this was the “over communicative” team lead I had — who was actually doing a good job. He used to enter extensive comments and give us more information than necessary in emails, etc. There were multiple instances when he could not be reached and we could simply go over his copious comments to get all the information we needed to move ahead during a crunch time.
It is extremely important for the manager to identify what behaviors to encourage, and know how to effectively manage an offshore team. Otherwise, chaos reigns no matter the team size or the technical capability of the offshore developers.
To be continued…