👨‍👩‍👦Triptych – the ideal structure for tech teams 👨‍👩‍👦

# [ $davids.sh ] · message #228

• @ [ $davids.sh ] · # 1297

  . Team Lead (Ears & Mouth) – the single point of entry for the business, responsible for delivery timelines, the technical backlog, and team health, creating conditions for Senior and Middle developers to work.

  . Senior (Brain) – responsible for the quality and operability of the entire system, which means: making technical decisions, having veto power, putting out fires, and creating technical conditions for Middle developers to work.

  . Middle (Hands) – responsible for the operability of the code they write: agreeing on decisions with the Senior, developing features, and verifying that they work.

  Notes

  . I've named them "Team Lead," "Senior," and "Middle" because there are no better words (besides those in parentheses). In reality, a "Middle" role can be filled by someone at a Senior level, or even a Junior.

  . These are ROLES, meaning one person can embody multiple roles.

  . However, there should be a maximum of one Team Lead and one Senior. There can be many Middle developers, but ideally no more than ten.

  . A Team Lead may not have technical skills (I call such people PMs, but this does not absolve them of the responsibilities described above).

  . I have intentionally excluded QA, DevOps, CTO, Architect, etc., because these roles can either reuse the above descriptions or are more exaggerated versions (e.g., a CTO is a Team Lead who is also responsible for payroll).

  Why this specific team structure

  . Decisions only become (in)correct after you implement them, so someone must simply take responsibility for choosing a path and waiting for the result. If multiple people try to approve such a decision, they will encounter significant problems. Therefore, there should only be one captain (Senior).

  . Communication with the business is a pain. It can be incredibly extensive, both incoming and outgoing for the team. At the same time, the business often doesn't know how to communicate with developers, and vice versa, so it's best not to let them interact constantly. They can be introduced and work together for a period (feature development), but all communication and responsibility should be in one pair of hands (Team Lead).

  . Seniors complement Middles, and Middles complement Seniors: Middles can gain all the necessary knowledge, while Seniors can realize themselves as "senseis" and learn themselves by structuring their knowledge while transferring it to Middle developers. This Ouroboros allows both of them to grow and enjoy it.

  Two Senior developers might (initially, get into a fight, but I mentioned this above, so in this situation) ask each other too few questions (due to shyness, for example) and develop some incredible nonsense simply because they didn't dare to discuss it beforehand (this is generally about maturity, but that's a separate topic).

  How to create such a team

  – Openly and clearly state who is taking on which role, and ensure that Seniors explicitly transfer decision-making rights on business matters to the Team Lead, and Middles explicitly transfer rights for technical decisions to the Senior.

  – Establish good, open, and constant communication between all these links.

  – Give Seniors the opportunity to make technical decisions and hire people accordingly.

  What are the dangers

  – If the Team Lead has poorly developed soft skills and lacks the "steel balls" to say "no" to both developers and the business, everyone will burn out, the business will suffer, and turnover will begin.

  – If a bad Senior is chosen, they will lead the entire team to ruin. At the same time, if a Senior is not given the right to make risky decisions, even a good Senior will be unable to do anything.

  – If Seniors are not willing to listen to Middles, or Middles are not willing to agree with the Senior's final decisions, the scheme will not work. Therefore, it is the Senior who should assemble the team.

• @ [ $davids.sh ] · # 1298

  And yes, it's obvious there are a billion nuances, a billion "BUTs," and so on.

  One could write endless books about this.

  I've listed the juiciest bits and the most average characteristics / problems / solutions.

• @ Ivan ITK 🚫 · # 1299

  Somewhere a jun was crying reading this post

• @ [ $davids.sh ] · # 1300

  Oh, right, exactly, I forgot, I'll try to cram them in now

• @ [ $davids.sh ] · # 1301

  I called them "Team lead", "Senior", and "Middle" because there are no more suitable words (except those in parentheses). In reality, a "Middle" role can be filled by someone at a Senior level, as well as a Junior.

• @ [ $davids.sh ] · # 1302

  Added

• @ Ivan ITK 🚫 · # 1303

  There are various ways to resolve conflicts between seniors:

  • Assessment of available resources, planned effort, and business justification for each solution.

  • Two columns of pros and cons for each solution. Two 10-minute rounds; in the first, one person criticizes, the second finds pros in their solution, then they switch roles. In the end, they count the pros and cons.

  • As you outlined, role division, but this is the CTO's task. Senior grades in PDPs are in different niches; each has the right to make the final decision only within their own area.

• @ Ivan ITK 🚫 · # 1304

  I'm experimenting here, by the way, with having the team lead in teams not be a senior in technology, but rather, their mindset be more focused on processes and people. So that if there's a technical problem, they don't pull the expertise to themselves, but rather keep the level of madness and cargo cult within the department's ward at a normal level.

• @ [ $davids.sh ] · # 1305

  Are you talking about 2 seniors within the same team?

  I didn't understand the first point, we practice the second one between seniors from different teams (but this is more like a consultation), and I agree with the third one.

  Overall, I believe we need either (1) one person to delegate more decision-making authority to the other, or (2) responsibility to be divided so as not to overlap (even by modules within the same system).

• @ Ivan ITK 🚫 · # 1306

  Regarding the first point, I simply described the basic decision-making factors that are not directly related to technical justification, but were more about risks and management. This way, it's easier to filter out most decisions in the initial stage.

• @ [ $davids.sh ] · # 1307

  Absolutely agree.

  In my experience, due to resource constraints, it happens that a Senior also becomes a Team Lead.

  And whenever the Team Lead was a separate person, who was more focused on people and business, but generally understood development (ideally Junior+ or Middle-), then the processes went much, much better.

• @ Ivan ITK 🚫 · # 1308

  I'm also coming to the conclusion that this is much more effective, plus he understands the team atmosphere better from within than a technical person would.

• @ Vladislav Yucca Y. · # 1309

  Idea: A game show called "Imposter Syndrome." You take 10 senior engineers and tell them there's one salesperson among them who has been coached to spout buzzwords. To win, they have to figure out who the fake developer is. The twist: there is no salesperson.

• @ [ $davids.sh ] · # 1310

  Or 10 juniors, and one of them is a senior

  Nuance: all are seniors