Every engineer, in their career, hits a phase where they have to answer the million-dollar question of whether to switch on to managing other engineers/team or continue being on the technical side ? Couple of years back, I had to face this dilemma too and just like every other ambitious engineer, I said, I want to give a shot at managing but at the same time also want to be on the technical side. So ambiguous, right ? But I found out that almost greater than 50% engineers were in the same boat.
Well fortunately in my case, I got an opportunity to do the exact same thing. We called that role, “Tech Lead”. The responsibilities of the role were to lead a team - product development wise, and also have hands on in designing as well as if time permits, do some actual coding. I got to learn lot of things from this role, mainly on the managing side. We as a team grew and were able to successfully deliver on our commitments quarter after quarter. In this journey of mine, I constantly tried to keep the team strong and motivated and make maximum impact as a team. Below are some of the qualities that I practiced, which helped in nurturing healthy culture on our team:
Trust
Trust is a fundamental key for management. Trust is an intangible asset, which helps the transmission of knowledge and the voluntary assumption of responsibility. A team can progress only if they trust their leader and their leader trusts the team, be it an engineering team building software or a team on battlefield. There are couple of ways we can achieve that trust:
Not micromanaging is one of them. We might not be able to achieve this right away and one might fail miserably in its implementation. Being an engineer myself, I always wanted to do things on my own and overlook constantly on what others are doing so that we can make to our commitments without errors. But once I relinquished quirk of overlooking everything, it had two main effects:
- Engineers on my team were assured that I trusted them and they started taking more responsibilities on their own.
The second way to gain the trust is to always have your teams back, in good times as well as in bad times. One of the philosophy that I believe in and practice is that to be a good leader we should always put the team in front in good times, like during achievements and take the full responsibility as a leader in bad times, for example when your engineer does something terrible, which takes the cluster down. This helped me a lot in gaining my team's trust.
Transparency
Being transparent generates motivation and keeps the team culture healthy. Always try to answer the “Why” question. I myself would not like to work on something for which I don't know the valid reason to do so. Surely being in spot of the lead, there will be things which you cannot share immediately with the team, but we should still try to be transparent as much as possible.
One of the things that we practice is publish leadership sync notes, internally, where its visible to everyone. That way all the engineers on the team know what is going on at the leadership level. Also, we publish our design notes and have discussions on the same post, so that its visible to everyone. In every team meeting we try to share on what is coming next and why we need to do that and how we are planning to do it. We should try to be transparent not only in terms of development work, but also in terms of certain decisions we make. May it be why we chose to use this technology vs other or why the support rotation and responsibilities changed.
Motivation
We should always keep our team members motivated. Showing the bigger picture and discussing how even the smallest work an engineer does, affects and fits in overall picture is very important. The other aspect is listening to the team members and trying to resolve/provide their needs. If an engineer is interested in doing projects other than what he/she has been working on, I try that next time when we have that project I give it to that person to work on. It also helps in not having a single point of expertise for certain type of projects.
Other important activity one can do is to equally participate in everything as an engineer. Be it the support rotations, staying late to meet our commitments or even if it’s something minor like giving scrum updates. I try to do each and everything that I expect my team to do. This keeps them going and achieving their goals. Another way, which I just started doing some time back, is encourage team to participate in hack-a-thons, conferences and write blog posts, whenever they feel they achieved something, which other teams have not.
And lastly, empowering individual team members and making them own the projects also helps in keeping them motivated. Of course, appreciation (I am going cover that below) and activities like team lunches, movie weekend, game day, etc., help too.
Freedom
Freedom is a very broad subject. But we can certainly give some level of freedom to engineers on our team. Freedom to make some technical decisions, freedom to own something, freedom to put out new ideas without the fear of getting shut down immediately, freedom to participate in design discussions, etc. I feel being a lead you become more comfortable with that kind of freedom automatically when you develop that trust in your team. But a very important thing to keep in mind is that freedom should not be misused. We should always keep reminding the engineers on the overall goal and commitments we need to work on and how important those are at the same time. One way I personally did this is by syncing up with each team member and making sure they understood what we are trying to achieve as goal and how much if we can or cannot deviate from the initial plan. Also, any ideas that engineers put forth, can be posted internally so that even other leaders can see the same and comment on it.
The other type of freedom is around time. For example, allowing engineers to come in late on somedays, to work from home or to leave early occasionally. I personally feel if the work is getting done in time, we should not mind those requests if it’s not getting abused. The only thing I tell/discuss when someone on my team asks for any such request is that an engineer owns the code he/she writes and it is his/her responsibility to make sure it gets deployed all the way to production on planned time. If they can achieve that I typically don't deny such requests.
Availability
We should always be available for our team members. I personally have Slack installed on my cell phone, so that even if I am not in office I can respond to the team, if required in urgent cases. But being available physically is not the only aspect of it. We also need to be available for code reviews, meetings, 1:1's (never miss this one), design related questions, kick off meetings, etc. We should make sure that we are always open and available for questions/suggestions from engineers on team. Of course, there will be times when you are busy with meetings or other managerial responsibilities, in that case we should make sure that we follow up on any questions that the team/engineer had. Also, being available means that if any of the team members need help to accomplish his/her task and are having road blocks in doing so, then we being the leaders, should assist them in clearing out that blockage. That can include asking for extra help or getting tasks done from sister teams or even outside of your organization.
Appreciation
There have been numerous studies on the relationship between gratitude and work engagement. Showing gratitude can increase a person’s wellness and lessens stress. This directly impacts work results and employee interaction. With appreciation, we’re not only boosting performance and engagement, but also the engineer's well-being and health. Few ways in which we try to implement this in our team are:
In our retrospective meetings we make sure everyone gives +1/kudos to someone from the team or outside of team who helped achieve one’s success for the iteration. We then tag that person on the retro notes when we publish them. That way both the person giving +1 and the person receiving +1 are visible to everyone internally.
There are also many different awards for which, we can nominate someone for, like 'you rock' award or 'Dev achievement' award. Each award comes with announcement from senior leadership and is published internally for visibility. It includes a gift card based on the award and the work for which you get the award.
I personally feel even a simple offline conversation like 'you're doing great, keep up the good work!’, makes a huge difference. Always try to appreciate the good work your team or individual on your team does.
Along with the ones mentioned above, I also found couple of other qualities to practice, for a team to be successful:
Regularly put the interests of team/engineers before personal interests. We should try to build and let our engineers grow as well. Try and train them to be your successors.
Almost every engineer on the team, these days, is on some social media platform. I highly encourage my team members to follow people who are from technical background, and whom they admire. I encourage engineers to read their blog posts and try to learn and implement some of that within individual work or within team.
Of-course things said are easier than done. All of the above practices that I have mentioned didn't happen or I didn't start practicing them overnight. It will happen in iterations and finally after many such small and repetitive steps, you and your team will be at that sweet spot. And not necessarily all of the above will fit perfectly for all teams. Being lead, it is up-to us to find out what works best for our team and what makes it, the team that makes the maximum impact.
Top comments (0)