I am a tech lead in a team. I was doing a lot of the team lead work because there was no team lead up to now. The team has mixed feelings about pair programming. The main reason for this is that some people (who don't produce) use pair programming to hide they are not contributing. The team has a lot of consultants and they are in general reluctant to formally complain.

I am trying to defend the team by avoiding mandatory pair programming. The new team lead wants to enforce mandatory pair programming mainly based on votes from people that do not produce enough. Under whose domain falls pair programming? Is it a technical decision that tech lead is driving or is it a team lead decision that the team lead is driving?

  • 4
    If anything, pair programming is more likely to keep the less productive team members on-task. Commented May 19 at 4:03
  • Are the less productive likely to get more productive over time? Commented May 19 at 13:52
  • 2
    Do you now report to the team lead? Are they your line manager? Commented May 19 at 20:30
  • @NeilSlater no i report to the lead Of the team lead. We report to the same manager.
    – Pesho
    Commented May 19 at 23:25
  • 1
    @HappyIdiot i don’t know honestly. 50% Are old complacent emoloyees, utvis a public sector project. The rest just do not seam very skilled, maybe there is some hope for them. Hard to tell.
    – Pesho
    Commented May 19 at 23:27

2 Answers 2


Both. Neither.

The tech lead and the team lead must work together to get the best outcome for the team. Trying to divide up responsibilities into "tech lead decision" and "team lead decision" is a recipe for disaster.

To say the quiet part out loud: if the tech lead and the team lead can't work together, senior management should step in and replace one of them if they can't learn to work together.

  • Leaders got to lead. This isn't a large enough responsibility to split the decision making authority. Whether this happened because of peter principle or a failed test, it time to move onto a different method of managing. Something that doesn't encourage the non-productive to hide behind the productive.
    – DogBoy37
    Commented May 18 at 19:12
  • @Pesho What I mean is that there isn't a large enough team (50 to 100) to require having such miniscule decisions split between two people. How you perform tech typically is tech's responsibility. My point about how the situation got here, was now that you know that it isn't working - fix it. That you identified less productive people hiding behind more productive people via team programming is what needs to be fixed ASAP.
    – DogBoy37
    Commented May 18 at 23:20
  • 2
    @DogBoy37: Consultation and cooperation is not abdication. There does not have to be a single person in charge of everything, as long as everybody understands who is. The answer to the question of who owns this is that they need to share it, or negotiate that themselves, or have management decide if they can't resolve it themselves. Any answer can be made to work.
    – keshlam
    Commented May 19 at 0:52
  • 3
    Hiding lack of productivity, if that's really what's happening, is a separate issue from pair programming and is Management's responsibility to deal with.
    – keshlam
    Commented May 19 at 15:23
  • 1
    Different companies use the same terminology differently, and tolerate different degrees of variation in practices. And junior managers still have more senior managers holding them to their responsibilities/commitments; that's still a management issue unless you are willing to try to manage upward... which is as touchy as juggling nitroglycerin, and someone who could do it successfully probably wouldn't be asking this question.
    – keshlam
    Commented May 19 at 23:39

Under whose domain falls pair programming?

In companies I have worked for, it is the individual developers on a case-by-case basis. They might be encouraged to use pair programming as a tool, and this can often be negotiated in daily stand-ups. If someone is blocked on a task, then a session of pair programming is often recommended, and a volunteer asked for.

The more general answer is "it depends", because the culture of a team of engineers that impacts how the work gets done, is something built up over time. The responsibility between you and the new team lead wil also depend heavily on whether you now report to the team lead (i.e. are they effectively your manager, and you a senior technical expert within their team). Ideally you both agree broadly on how heavily you want to lean into pair programming as a tool, because the team lead is responsible for the teams welfare and project delivery, whilst the tech lead is responsible for understanding and helping to design and implement components that achieve those things. Mandatory pair programming is very heavily leaning into the idea, and is not the only step you could make at this stage.

Any decision on mandatory behaviour from skilled staff who are capable of acting in open-ended fashion towards allocated goals (of which software developers are one example of) should be examined carefully and have very solid reasoning to enact. These staff are expensive, and making what to some might be radical changes to their working practices will inevitably lead to a fraction of them disliking the change.

You have somewhat painted yourselves into a corner by putting the idea to popular vote. However, if the results were not unanimous, you have a strong reason to start with a trial period where it is not mandatory.

My recommendation would be that the developers who voted for pair programming should be encouraged to make use of it with both your blessings. Developers who expressed reservation or voted against doing pair programming might be encouraged to give it a try, or the team lead could spend some time listening to their reservations in one-to-ones (or whatever feedback structure you have in place) to help inform them.

As tech lead implementing pair programming, your part of the work should be identifying areas of knowledge that would benefit from being shared. Also maybe identifying any toolkit or technical artifacts that could help.

I would expect the team lead to take the role of consulting staff, and getting buy-in.

Outside of tech lead but specific to your history as "acting team lead", you could pass on knowledge of team dynamics and behaviour that might help inform them. Which is maybe how your concerns about less productive staff could be communicated.

  • 3
    Right, it's not a jet airliner where having 2 pilots is the only sane approach. People work together when they need to. But it sounds like the 'need' is that some folks are "not getting enough done". If two together get more done than two apart, ok. If it just slows down the faster one to no benefit, then not. Should do what is effective and not worry about feelings. Commented May 20 at 0:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .