1. It's always the team
Its not about you anymore. It's important to keep aside your ego, the competitive in you and jealousy. The solutions should be discussed and it's okay if a junior or a competitor proposes a better solution than you. You would need to grow a open mind to embrace the best solution, no matter from whom it comes from.
I learned to start the meetings by stating the problem, and the first line post that would be 'So anybody has a solution in mind?'. If I propose a solution myself, I learned to end the sentence with 'I am open to suggestions and feedback'.
At the same time, it's important to groom your team to be open and forthcoming with their ideas. Providing the best technical solution is not enough, it's important to find the right balance between technology and business. Hire the right people, who can groom if needed, and trust eventually.
2. Technical debt is a bitch
You can run but you cannot hide!
If we ignore the debts for too long, it will come back and bite you. Often the timelines are so tight that the technical debts are ignored and just sitting in the backlog. It's frustrating when the managers and business does not give enough importance to the technical debts and they just remain a number in your release notes, only addressing the blockers, or getting the low hanging fruits to maintain an acceptable scores in the various tools to keep the Quality team happy.
That's where our skills are put to test, convincing the business to address the technical debts. A few every sprint and you will see the difference. Easier said than done, but its worth to keep trying.
3. Find the balance between business and the technology
Instead of the attitude to 'get the story done', it's important to see how the solution will fit the business and raise flags if you think it would not work as per the customer's need, or if you think it breaks or contradicts any existing feature.
With years of grooming as a developer, its easy to get shortsighted and only look at a problem from a technical stand point. We usually concentrate in providing the best solution possible in terms of technology and often ignore the big picture. Also, its extremely lucrative, how we can introduce a new cutting edge technology to solve a given problem, but the business often has no time, no budget, and no risk appetite. Frustrating as it might sound, I have learnt to respect that. From a business standpoint, there has to be a balance between the time put in explore and learn this new technology vs the benefit it would actually bring in to the project/ app.
Put in some personal time for a POC if needed and if we can show the stakeholders that we can get it done, then its a win-a-win.
4. Wear any hat that the team needs
Don't consider the non-technical people as muggles, or look down on any role.
In the last couple of years I have worked as a QA, Developer, Support Engineer, Business Analyst, Architect, OPS, Scrum Master and often filled in for the Product Owners as well. I had this whole stack of hats hanging in my coat hanger and wear anything that the project needed at that point.
While it helps unblock the projects at various points, it also added to my personal profile. It helped me build a lot of relationships beyond just my team, my project, my role and profile. The more people you engage with, increases your visibility among multiple stakeholders. They are also more likely to get you involved earlier or give you relevant, timely feedback. Those relationships are important.
5. Leader is known by his followers
Finally, every time any of my mentees have thanked me, I have said the same thing. A leader is known by his followers. Try to mentor the team, keeping in mind that you need to groom them to be independent and eventually have them mentor others some day. Quoting an example from my own experience: every time a team member approached me with a query, I always took time to explain them the history and relevance of the solution and not just how to solve that particular story/ bug. That way, they stay engaged, understand the whole ecospace of the project (technical and functional) and will start getting the big picture sooner. I learnt that from my first mentor.
Its not about you anymore. It's important to keep aside your ego, the competitive in you and jealousy. The solutions should be discussed and it's okay if a junior or a competitor proposes a better solution than you. You would need to grow a open mind to embrace the best solution, no matter from whom it comes from.
I learned to start the meetings by stating the problem, and the first line post that would be 'So anybody has a solution in mind?'. If I propose a solution myself, I learned to end the sentence with 'I am open to suggestions and feedback'.
At the same time, it's important to groom your team to be open and forthcoming with their ideas. Providing the best technical solution is not enough, it's important to find the right balance between technology and business. Hire the right people, who can groom if needed, and trust eventually.
2. Technical debt is a bitch
You can run but you cannot hide!
If we ignore the debts for too long, it will come back and bite you. Often the timelines are so tight that the technical debts are ignored and just sitting in the backlog. It's frustrating when the managers and business does not give enough importance to the technical debts and they just remain a number in your release notes, only addressing the blockers, or getting the low hanging fruits to maintain an acceptable scores in the various tools to keep the Quality team happy.
That's where our skills are put to test, convincing the business to address the technical debts. A few every sprint and you will see the difference. Easier said than done, but its worth to keep trying.
3. Find the balance between business and the technology
Instead of the attitude to 'get the story done', it's important to see how the solution will fit the business and raise flags if you think it would not work as per the customer's need, or if you think it breaks or contradicts any existing feature.
With years of grooming as a developer, its easy to get shortsighted and only look at a problem from a technical stand point. We usually concentrate in providing the best solution possible in terms of technology and often ignore the big picture. Also, its extremely lucrative, how we can introduce a new cutting edge technology to solve a given problem, but the business often has no time, no budget, and no risk appetite. Frustrating as it might sound, I have learnt to respect that. From a business standpoint, there has to be a balance between the time put in explore and learn this new technology vs the benefit it would actually bring in to the project/ app.
Put in some personal time for a POC if needed and if we can show the stakeholders that we can get it done, then its a win-a-win.
4. Wear any hat that the team needs
Don't consider the non-technical people as muggles, or look down on any role.
In the last couple of years I have worked as a QA, Developer, Support Engineer, Business Analyst, Architect, OPS, Scrum Master and often filled in for the Product Owners as well. I had this whole stack of hats hanging in my coat hanger and wear anything that the project needed at that point.
While it helps unblock the projects at various points, it also added to my personal profile. It helped me build a lot of relationships beyond just my team, my project, my role and profile. The more people you engage with, increases your visibility among multiple stakeholders. They are also more likely to get you involved earlier or give you relevant, timely feedback. Those relationships are important.
5. Leader is known by his followers
Finally, every time any of my mentees have thanked me, I have said the same thing. A leader is known by his followers. Try to mentor the team, keeping in mind that you need to groom them to be independent and eventually have them mentor others some day. Quoting an example from my own experience: every time a team member approached me with a query, I always took time to explain them the history and relevance of the solution and not just how to solve that particular story/ bug. That way, they stay engaged, understand the whole ecospace of the project (technical and functional) and will start getting the big picture sooner. I learnt that from my first mentor.
