Being a 'Technical Lead' or 'Tech Lead' means different things to some people and organizations; based on definitions found online, a Technical Lead is:
"A technical lead is a professional who oversees a team of technical personnel at a software or technology company. They often lead software development or software engineering teams and troubleshoot technical issues that involve software development, engineering tasks and product releases."
Although I agree with this, I would flesh out a bit more around architectural governance (or technical assurance, which is what the problem this role or function is for) across it - it also doesn't need to be software development heavy; it can sit in the operational and delivery spaces as well (waterfall or agile) and is more than a specific role, but a frame of mind.
At a very high level, this is what a day in the life of a technical lead means to me:
Day in the Life of a Tech Lead
- Work alongside: Technical Product Owners, Chapter Members, Architecture, Business stakeholders and Service Partners to develop/roadmap/architect and improve technology.
- Manage delivery and operational risks and dependencies, and remove impediments to the achievement of the team objectives
- Test and develop roadmaps for preview Cloud capabilities for immediate or future value
- Act as a Subject Matter Expert (or Consultant) to assist in Design Decisions, Monitoring, Cost and Capacity Requirements
- Develop Governance processes for onboarding services into BAU, enabling Technology Infrastructure and Operations staff to use technology in a consistent and secure manner
- Work alongside Security and Developers to enable cross-team visibility and collaboration
- Champion improvements in People/Processes and ways of working
- Work alongside Chapter Members and Chapter Lead to develop Training/Skill programs for Technical areas
- Develop and promote an 'everything as code', 'everything is automated' mindset
- Problem/Incident Management (i.e. Continous improvement)
A Technical lead mindset may look like below
- Automate what's trivial, boring, mundane, and belittling
- Build what you can't buy. Buy what you can't live without
- Make your work visible. Shift your value to performance.
- Work is never completed. Establish feedback loops.
- Target high impact problems.
- Get out of the way of the work, think outside of the box, don't limit others.
- Try, Learn, Adapt, Try again
- Agile is about speed to adapt, not velocity
- Log what's useful, monitor what matters, alert on what's actionable
- Empower others while making sure that everything is auditable, standardised.
- We live in a VUCA (Volatile, Uncertain, Complexity, Ambiguity) world, you will never see perfect.
The views above are my own, but shout out to Teal Unicorn for independent consulting on Ways of Working, Continuous improvement; I attended a few of their workshops on Ways of Working, Ways of Managing and Ways of Consulting, and it helped me take a step back and look at what this kind of mindset may look like, or should be and current blockers.
Overall, I have noticed that Information Technology roles are now blending disciplines that once required specific job roles (ie Business Analyst, Service Delivery Manager, Developer, Architect), although pure technical roles still exist with Cloud technologies, different skillsets are required to get the most value out of technology stacks, as technology becomes more consumable. You may also be interesting in reading my thoughts on: The Cloud Frame of Mind
Hopefully this has helped or at least encouraged looking at problems differently, or areas of improvements for any readers out there!