Being a technical lead on a project is a complex position with a lot of demands. Recently I have been thinking about what separates
the good leads from the bad ones and one of the main things that keeps coming up is ‘vision’, having an understanding ahead of time of the project’s technical and non-technical aspects and having goals and ideas on how address them. When you have a great lead it seems like they have anticipated everything and things fit together. There is continuity to the code. A direct result I believe in many cases of a tech leads creating a vision for the project, communicating that to the team, and making sure everyone is working toward the vision. I want to discuss some areas of projects where tech leads commonly lack vision because tech leads get focused on the technicals they forget some important non-technical aspects which are unavoidable.
Areas Lacking Vision
- Schedule – I know this should be the project manager right? Well yeah but a tech lead needs to anticipate what the best ordering of tasks is dependencies and what resources match best with specific tasks. Being a project where you are constantly realizing dependencies which previously weren’t thought to be there makes development painful in many cases. Yeah changing task order mid stream sometimes is unavoidable but put critical thinking into it at the being of the project and make sure tasks get started off with the possibility of the right order.
- Task Delagation – Creating a pattern for how tasks are going to be handed off could be a tech lead’s best friend. Just saying start on the task isn’t sufficient. Envision ahead of time how your going to kick other developers off on tasks and what you don’t want to happen. This will allow you to avoid lost time on the calendar and getting pulled in too many directions at once.
- Reviewing Code – This creeps up on far too many tech lead’s (myself included), assuming you practice having project code reviewed either internally or externally, preventing the ability to react to requested changes. Make sure to mentally anticipate tasks finishing and the who/when of code reviewing. The sooner you catch issues the better and reviews are assurance that team members are completing tasks correctly.
- Documentation – What the right documentation that needs to come out of a project is what I’m talking about here. understanding not only what useful client documents are needed but also documents for people who will be maintaining the project in the future. More projects than not that I come on after the fact as a developer and I think “I wish I had documentation on this”.
- Project Communication – Communication isn’t a problem for a lot of tech leads especially when everyone is base out of one office. The situation where creating a vision of how communication will play out is when you have team members in diffent locations. Relying on email just isn’t an option in most cases. Too many times communication becomes a problem because someone on your team isn’t available to communicate in real time. Work on a vision that mitigates those situations thinking about the obvious like meeting times but also the not so obvious like what tasks get assigned to who.
I’m a firm believer in working at the begining of a project to create a vision of every aspect of the project possible so you can work towards it and get the team to work toward it as well (so don’t keep it to yourself). Vision can change as things come up too so don’t chain yourself to the original vision, allow project members to challenge it and challenge it yourself. Afterwards if you feel like it needs to change then change it.