Everytime I get asked this question, I feel like I’m the author of a cheesy know it all engineering management book that either veers into turning managers into some messiah-like personality or some machevillian scheming personality. And the current perception from the Silicon Valley and elsewhere potraying managers as process monkey’s doesn’t help!
We have introduced the concept of a manager or a leader (and I’m purposefully combining both due to my distaste towards leader vs manager debate) for business reasons. Period. Nothing else. If it were a five person company, you wouldn’t be having a manager. If it were a fifty person company, you would be having people who would be doing part-time management. But, if were a five hundred person company, then you definitely need managers! The other alternative is that you have multiple people going to meetings, multiple people going the democratic method of voting for features etc. And finally, you spend the time of far more people who wouldn’t want to be there in the first place to be taking decisions, which anyways would have been taken effectively with fewer people anyways. Amazon tells that the most important attribute of a successful business is velocity. Ideas are everywhere, execution is what separates the successful from the unsuccessful companies.
So, the role of a manager is to help the business execute faster. We can call this as the output metric. But, faster is only applicable when you apply a time horizon to it. Faster in a week? Faster in a month? Faster in a year? or faster in five years? Gone are the days when you could promise the moon and expect to deliver in five years. In the cloud world and the agile world, your time horizon is ideally somewhere between three months to a year. So, as a manager, your success is judged by your ability to help execute faster in this timeframe.
To help a team execute faster, there are several things that need to be evaluated and looked at:
1) Is the team working on the right things? If not, the team will be executing on a bunch of random things and the cost of bootstrapping them cannot make the team fast. Each time a newer project comes, the team has pivot back and strategize again?
2) Are the processes helping the team to move fast? Does the team have transparency of knowing who is doing what, the progress of each areas and how to move things fast, wherever possible? To improve execution, people need information. If we don’t provide the information, they cannot execute effectively.
3) Are the right people working on the right projects? Are the projects that each one is working on the right one? Do they align with the individual’s super power? Do they get paired with the right people? Are the invidual’s motivated? Do they see a connection between their work and their goals?Are these individuals the right people for this team or company? Motivated people can deliver amazing things and can surprise you in delivering things that you have not even thought of!
4) Are the right tools and services in place? As software grows, so does complexity and complexity can slow things down. Can we simplify the architecture? Are there other ways to invest and improve developer productivity?
As you can see, an engineering manager is responsible for several of these and there is no order of priority. Depending on the team, the engineering manager needs to exercise their judgement and decide on the right problems. So, an abstraction on top of these general problems is that the engineering manager starts with using information to make effective decisions and then builds mechanisms to help the team and the organization take effective decisions. By doing so, the leader is helping the team to be effective in taking decisions quickly and not becoming the single point of failure for the team.
My engineering philosophy is centered on building mechanisms for teams to become high performing. A few things that I have found useful (either through reading or through my own experience) are:
- Create a culture of transparency. A manager should build mechanisms where the team is aware of and also contribute to the critical work that team is doing. I’ve found the three big rocks written in OKR format very helpful as it allows members to remember the critical things of their team as well use that for effective prioritization. This coupled with organization wide monthly meetings to celebrate the wins and lessons alongside bi-weekly sprints helps the teams to be aware of their critical items and the progress.
- Create Growth mindset. The chracteristics of growth mindset are that they see problems as opportunities to learn and improve and also the continous thirst for improving their existing and at times well working things. My 1x1 conversations and career progression feedback centers on things each individual does well and also a section on areas of improvement. The design docs and post mortem sections always focus on the things that could be done better and help critical thinking for the team to find areas of improvement.
- Be approachable. As an engineering leader, I want to be approachable by everyone in my org. I cannot do weekly 1x1s with 40+ people, but I will make it a point to build direct connections with the employees so that they can reach out to me, when needed.
- Have fun. As a leader, I take it upon myself to ensure that we are not treating the organization as a factory. Instead, it balances between doing great things and also having fun. Mechanisms I have put in place are things like engineer-led socials, organization-wide monthly meetups and celebrating special occasions. Its key for the leader to participate in this and not be the “boss man” trying to fit in.
