In Part 2 of my "Developer Leadership" series I cover self evaluation and understanding your team. These are important aspects when it comes to being a good developer with leadership qualities.
What do you bring to the table?
It's important to assess yourself and understand what you bring to the table. What strengths do you have that will empower your team to reach the success it needs? What weaknesses do you have that you'll need to be honest and transparent about and rely on others to fill those gaps? I want to cover some areas that can really help you shine no matter how long you've been on a team or your actual job title.
Researching tools for your team
This is perhaps something that I most love, and I often encourage others to do in order to really appreciate "doing better". When you run into an issue, how do you face it? Throw up a few more servers? Stack up tasks and tickets in Trello? Maybe you code something up for a few hours in order to tell when your website goes down?
Well, we as developers have it somewhat easy in a lot of ways when it comes to identifying and getting a start on solving an issue. There are entire teams and companies dedicated to documentation platforms, server monitoring, customer support, upgrading your Laravel version, and so much more!
Identifying issues within your team and product is pretty important to not only sticking with the team, but to also continue to improve it and add value. Let's say for example, you have a user report your website is unavailable at random times (obviously writing tests and having a Q&A session is vital, but things can still happen), how do we go about beginning to fix these surprises, especially since whenever you're online the sites are working fine? Let's see if we can find some sort of server monitoring service. A quick Google search reveals plenty of options both free and paid with varying levels of functionality and offerings. There are also plenty of Open Source alternatives. My point? You don't need to write something that pings your own server every minute, and then an SMS/Email sending service to identify when your site goes down.
If you're facing an issue within your team or product, there are solutions out there ready to implement with nearly zero-effort.
Knowing what will add value over complexity
You'll need to understand that any change or introduction of a feature of 3rd party software will add some complexity to your processes. Sure, having a system that automatically generates bug reports when a user encounters one is super helpful, but you'll need to ensure you're checking emails regularly and logging into the system to understand what's going on.
The more we can focus on actually improving the product and expanding it, the better. But there is a fine line here. Just as having a Bug tracking program is a great asset, you wouldn't want to introduce Jira to a small team and expect them to fully utilize it along with all of it's integrations. Atlassian makes amazing software, but it can honestly be too much for certain teams depending on size, scope of work, and the complexity of the product. Working with leadership can greatly help you understand what needs you should be looking to solve.
Understanding when culture clashes happen
No one wants someone coming into their team that makes a bunch of changes or indicates their processes are all completely wrong. Those exist for one reason or another, and it's what the team currently has that, for the most part, works for them. When you're introduced to a new team it's a good idea to go slow and be methodical in learning why certain processes are the way they are. With that said, there may come a time when the culture you're used to or desire is vastly different from what the team or product is.
Some teams are all about moving fast, deploying new features and then addressing issues. Others require extremely well thought out and detailed plans, utilize the waterfall methodology for development, and put the new feature through rigorous testing. That can really affect your productivity as a developer if your approach is different. Some people enjoy hammering away at things and shipping it with little thought, but in a team that requires lots of checks and testing, they wouldn't really flourish.
It's important to understand when your needs and work style aren't a good fit for the team. There are various outcomes, and none of them are positive and healthy to you or the team.
Get this article and more in my newest e-book
Pay what you want, $0 or $100 - Developer Leadership