---
# System prepended metadata

title: Tech Lead Responsibilities

---

# Tech Lead Responsibilities

## Open Questions

- Should the Tech Lead be an active builder in the project? Or should he be distanced from the day to day development?

**Namesty's opinion**: The Tech Lead should be part of the development team. He should be one of the project's builder. I believe there should be no "full time" TL; because the TL needs to be very familiar with the deep patterns, design, architecture, etc. of the project. What I've seen in practice, is that TL's who don't participate in the development process give shallow feedback and deep problems still make it through.

**Lanski**: for sure. Needs to be. I am not sure how to manage the case where there's only one engineer... should we require single engineers to be TL?

- How to handle a project where the client has their own TA-lead and that do not want one from us?

We probably still need a tech lead on the project even if we do not flag it explicitly to the customer, to ensure code quality, etc. for dOrg's reputation's sake.


## Current responsibilities (at least documented)

* Make sure you understand all technical requirements, and ask if you don't.

* Evaluate the experience level of each team member and offer mentorship if you see a need.

* Evaluate risk and raise potential issues with other team members, the Coordination Lead, Sourcing Lead, or client as needed. (**Namesty's opinion**: this one is probably either not being used or being misunderstood)

* Review pull requests and assist in debugging.

* Check for testing at different levels of the codebase.

* Structure the continuous integration/deployment pipeline and application alerts. (**Namesty's opinion**: not necessary. The TL shouldn't need to be the one doing this IMHO)

## Actual in-practice responsibilities

* Understanding of technical requirements
* Code review (Pull-request reviews)

## Proposed requirements
* 6+ minimum years of demonstrable professional experience in tech projects (Submit CV to the forum post)
* Knowledge of the whole stack: Frontend, Backend, Smart Contract and Web3 Integrations.
    * **Lanski**: Who reviews this? We need Jordan or Namesty to create a clear process for this. Can be done with swarms budget? Pope of Tech? Maybe just submit whatever they think it's relevant and gets reviewed by technical people? 
    * **Ops Sync**: reviewed by commitee - decide considering "sucessful project shipped"
* Grounded in the organization: 25.000k amount of rep. (They submit their address with the REP) considering not all members with rep have shipped sucessful projects. 
* **Lanski**: Ability to present the developments to the client on a weekly/monthly basis.
* Client satisfaction

------
A background check with previous teams will be done by Lanski & Clara to qualitatively assess the opinion from former team mates and clients. Metric: "sucessful projects shipped".D

------
A committee will review the applications:
- They will check that requirements are fullfilled. If not, they will veto.
- They will do background check
- They will receive VETO applications from people and review them. They might privately contact the person who has vetoed for clarification.

Who will form this committee:
- Lanski
- Clara
- 3 TL with more rep (namesty,cesar, ben?) + define which is their speciality
- Backup persons (decided by our top 3 version)


## Proposed responsibilities

Namesty: 

* Accountability: For this to be fair, there needs to be a way to escalate problems before they explode.

* Overall code quality: spotting anti-patterns, hacks, unnecessary complexity all around the repository.

*Practical example: while working on a login feature, the tech lead spots an unhandled API case in the already working login http service. Even if it's not his feature, and the review or the login http service already happened; the tech lead should spot this, communicate it and push for its correction.*

* Putting out fires: solving code-design issues, help the team make it through unexpected obstacles (incompatible libraries, broken code, uncaught bugs, etc.).

* 