The purpose of this document is to list expectations placed on people in tech lead roles with the intention of avoiding responsibilities falling "between chairs."
Some of these responsibilities are currently covered by the CEO, and our flat & small organization with highly skilled people means a lot of this is handled implicitly by everyone. As the organization grows responsibilities may need to be formally offloaded onto tech leads. The list is neither exhaustive nor presented in any particular order:
- Be familiar with and uphold the ACM code of ethics: https://www.acm.org/code-of-ethics
- Help leadership identify and analyze potential opportunities (market, tech)
- Help leadership convert opportunities into actionable plans
- Help leadership prioritize plans, tasks
- Help leadership find, recognize, assess, and mitigate risks
- Help leadership with hiring decisions for technical roles
- Ensure our technical roadmap is affordable in the short term and useful in the long term
- Ensure hard-to-reverse decisions/designs are well considered, e.g.
- High level architecture
- Network protocols
- External API surfaces
- Serialization formats
- Help devs reach personal/career goals
- Put pressure on leadership in case any employee is treated unfairly
- Challenge and if necessary disobey orders from leadership in case tasks/plans/products/services are harmful to:
- Society
- End users
- Customers
- Employees
- Business partners
- or anyone who's personal information is tracked by your systems
- Ensure opportunities exist for devs/leads to teach each other new skills/info
- Ensure work outputs reach the quality and demands necessary for any given project
- Uphold good security practices, ensure all systems are designed with security in mind
- Help unblock tasks
- Lead design, modification, and retirement of procedures for
- Incident response
- Addressing systematic issues, e.g.
- Ensure code review is useful and fast
- Ensure regularly scheduled meetings are useful
- Ensure regularly scheduled maintenance tasks are performed, e.g.
- Certificate renewal
- Monitor mailing lists for CVEs
- Check own
abuse@example.comandsecurity@example.cominboxes - Updating dependencies (as needed)
- Ensure dev envs, code, build systems, infra, and procedures do not accrue too many annoyances for devs
- Encourage devs to study and understand customers and market
- Find tasks in code and infrastructure that need to be done
- Assign tasks to "the most appropriate" dev or team
Most, or all, of these are tasks best done together with the devs. Devs should have power to make decisions about the work they are doing, and should be given opportunity to learn the skills to become tech leads.
Prefer presenting a task to the devs, asking if anyone actually WANTS to do it. But all tasks can not be handed out in this way. Some tasks are boring to everyone on the team. Some tasks must be assigned differently due to other considerations. Non-exhaustive list of important considerations listed in no particular order:
- Ensure workloads are compatible with sensible work-life balance
- Ensure bus-factor remains low
- Ensure devs feel ownership of both their specializations and project as a whole
- Task skill requirements (e.g. cryptography, hardware/embedded, language, etc)
- Externally imposed deadlines (clients, market, promises/obligations)
- Dev enjoys a particular type of problem
- Dev enjoys a particular domain
- Dev wants to learn some related skill or get into a new problem domain
- Dev identified the task (problem/opportunity) and is excited to take charge
- Tasks considered boring by all should be spread evenly across devs (best effort)