If your operating a development team, it’s important that you have a technical lead onboard that’s overseeing development operations on your projects – a role that is often coupled with the responsibilities of a SCRUM master, but they’re not the same…
Introduction
I’ve worked for many organisations in the past who’ve employed an obscure amount of in-house developers, all branded with different specialities, because the systems that they built, and the manner in which they built them, meant that they needed it.
Their overheads were massive; their project turnarounds were big, their solutions were riddled with technical debt and costly bugs and problems would come up far too often.
The team had fallen into a rut – and their philosophy for tackling problems was often branded: ‘this is how we do things here’ – rather than ‘this is how it should be done’.
As a developer, have you ever onboarded onto a project that is ridden with technical debt, has a disastrous build and deployment pipeline, lacks documentation and transparency, and contains so much bad practice that you sit there and think, .’wow, if I work on this project for too long, I might pick up some of these habits!’.
Every project needs a technical lead, it’s a price worth paying, and below are 6 reasons why.
1. Quality assurance
The job of a tester in any typical Software Development project is to ensure quality from a functional perspective. If it’s a website for example, they make sure everything works as it should across all of the supported target devices, and ensure that it works to in an intuitive and easy-to-understand manner.
But what about behind the scenes? Who takes responsibility of the quality of the code and implementation?
A big part of the technical lead role is to offer guidance and support to ensure that development practices are followed to a quality standard.
Technical debt is a dangerous and costly pitfall, and it’s imperative that organisations do their upmost to keep this to a minimum – or they risk big and costly overheads coming their way.
A hands-on technical lead should push towards a quality and consistent level of standards that all software project deliveries should adhere to.
It’s all well and good introducing a code-review process for the development team, but in order for it to be taken seriously, an enforced and up-to-date set of development standards need to be in place to act as a reference point in the code review.
And moreover, these development standards need to encourage the use of modern best practices, and the team need to be fully educated on these – with regular review sessions and wider input actively encouraged.
2. Stability
Is there anything worse than production issues? What about the production issues that you cannot figure out because you haven’t got a concrete logging implementation or debugging process in place?
Or even worse – regular system outages.
A production bug shouldn’t happen. And if it does happen, it needs to be taken with the upmost of seriousness and a full root cause investigation needs to be conducted along with a follow-up to introduce steps to reduce the chances of it happening again.
Does the testing process need to be improved? Were the requirements correctly documented? Why wasn’t it picked up during UAT?
Production issues will always come up unfortunately – its a feature of the software development world we live in today. But when they do happen, it’s important that your organisation is prepared to deal with it in an effective and efficient manner, and a technical lead can help steer this and take responsibility.
3. Onboarding
Onboarding. A subject I’m religious about as many organisations these days unfortunately overlook it and don’t consider its importance.
A successful onboarding strategy is the key to the success of a project – and if you operate in an organisation where developers come and go all the time, if your onboarding isn’t up to scratch you risk a dent in the quality and reliability of the software that’s eventually going to be delivered.
An effective onboarding strategy will bring many advantages – including cost savings in the long run and a major increase in productivity.
However, onboarding isn’t always easy to get right and feedback is paramount – a technical lead can champion this.
See also: 10 reasons a successful development onboarding strategy is paramount
4. Mentoring
Technology should be at the forefront of your development team – and in order for this to be the case, it needs to be at the forefront of the minds of your developers.
Mentoring is a way in this can be achieved. But mentoring shouldn’t always come just from the technical lead – it should be encouraged across your development team so that they can mentor each-other!
Regular “lunch & learn” sessions with an objective and purpose will keep developers technically challenged. Setting up a committee within the team to run these on a regular basis will enable developers to keep up with modern trends, and it’s also super-fun and engaging for all involved – not to mention it will grow the team and encourage a technology-driven culture.
5. Happiness
Developers can be hard to retain with the current market and opportunities out there, so organisations need to do their upmost to ensure job satisfaction or they run the risk of a “revolving door” culture.
A seasoned technical lead can help bring that to the table.
What sounds more attractive to you as a developer? Onboarding onto a project, with a strong and mature set of development standards, tools, and design patterns all in place, with a strong focus on ensuring quality assurance from the code and adhering to industry standard practices such as SOLID (along with a structured onboarding process to cover all the recommended training, education and mentoring required to bring you up to speed with all of this).
Or a project that doesn’t have anybody taking ownership of the quality of the technical delivery. A project where most things have been ‘up for grabs’ by whoever is working on it, with no technical guidance or review process, no development standards and essentially an open sandbox for a dev to come in, write whatever working code they wish to produce to get the job done, and not having a care in the world in terms of the future maintainability of the project.
6. Security
What’s to stop your developers from adding code into the platform that introduces a backdoor for them later in life? Or introduces a major security vulnerability, perhaps by accident?
If there’s no concrete code review process in place and this is enforced, developers are free to do as they please.
Hope that ISO27001 auditor isn’t due any time soon.
