So you’re not in the role you want to be in. Or maybe that promotion you fought so hard for you didn’t get. Maybe people are asking you to go into a different lane then you’re in now. Whatever it is – you’re not where you had wanted to be. But maybe it’s where you need to be to realize you should be somewhere else.
You can tell a lot by a team on how they work together when a critical bug is logged, 4 days prior to release. Either it’s the blame game as to who touched it last, what they were doing, what they knew or didn’t know or how dumb they are to really let that happen. Or it’s the team that rallies to understand the problem, look at it from all angles, figure out a plan…
The new guy doesn’t know where you keep your git library. They aren’t sure what libraries you are using. They probably have no idea who uses your software or why. To work on the bug you just gave them will take weeks, not days or hours. If you are hiring a new member of the team, recognize that it will take 2 – 3 months to learn what they are supposed to do and start…
Stay on the same course as everyone else. Don’t colour outside of the lines. Stay in your box, maybe make it smaller to be on the safe side. Don’t try anything new, do what everyone else is doing. After all, 1 million, billion cannot be wrong, can they? Stay the course that is safe and well worn by those in front of you (no need to create a shortcut to get their faster). Never try…
Then I guess the team is too busy to design it? Too busy to code it? Too busy to test it? Too busy to fix it? Too busy to help? If you’re not willing to take the first step towards resolving your problem, writing it down, then how do you expect to get others on board to help you? Aside: Needing help from others on figuring out your problem is a great idea to figure…