Enforcing SW tools as a technical team lead?

Question

I am a technical team lead in a team of consultants. We have a software tool which we apply for a specific problem. The tool was started by me about 4 years ago, and was used by a bigger and bigger fraction of the team. This leads to tasks and input files (models) being exchangeable and well understood within the team, which is a great asset.

Recently a new consultant joined off-site, and he insisted in his first project to use his own excel-based tool. I analyzed it, it has a subset of functionality. In the ares of engineering where we work the guy is competent, but he grossly overestimates his SW skills (~3 Programming languages,8y of experience) in comparison to mine (~13 Programming languages, 24 years of experience).

My opinion is that it would be bad for the team if we allow a second tool to be used, especially since it's a badly understood/documented excel sheet.

Now my question: Is it the function of a technical team lead to define (and if needed, enforce) the tools which are used in a team for common tasks?

Answer 1

I had to do an all-hands on this once when we had let things get out of control with everyone using their own tools. People couldn't take over from each other, even something as simple as writing up some notes was leading to tool time with people having to install readers and whatnot for each other's weird file formats and I finally "clicked" on the key issue.

It's productivity vs predictability and it applies to a lot more than just tool choices. People need to know what they will get from you and count on when they will get it. The overall productivity of the team is what matters.

Yes, you might be 10% more productive if you get to use your own tools. But if your 5 team-mates are each 3% less productive because of your choice (converting files, asking you to do it for them instead and waiting, etc) then the net effect on the team is a loss. Heck if you are 100% more productive and 8 people are 15% less productive it's a loss. You can't always go for the local maxima (your own velocity) and ignore the team.

In your particular case, I would say that the offsite consultant can use whatever they like to achieve a result, but the result needs to be submitted in a form that's consistent with the tool the rest of the team uses. That's a requirement of the gig. Whether that means using your tool, or doing an export and spending a day adding an import to your tool? That's an implementation detail.

Answer 2

The team lead should define which tools are preferred but only enforce them when real issues arise.

Having led teams at different organizations, I would suggest encouraging team members to use the same tools for the sake of efficient collaboration and hand-off. Given that you have a team of consultants and the member in question is off-site, I would be even more careful how you approach this.

A team lead who is authoritative and forces team members to abide by certain practices and tools will quickly lose respect. My top goal when leading a team is to build good working relationships and help the team be productive. At the end of the day, I don't have time to nitpick every detail about how the team works.

I would suggest that the new team member use the same tools and provide reasons why this is important, but that's it. I wouldn't bring it up again until the use of the tools causes real issues with the team's collaboration or productivity.

In my opinion, the only metric that matters is whether the team is providing value to customers or stakeholders.

There is a good discussion on Software Engineering about this: What is the role of the lead developer in an agile team?.

Answer 3

Counting software languages might be nice for the ego, but irrelevant for this question unless all of them are in use on the same project (in which case, Excel is not your issue).

If your consultant uses his Excel tool for his own use, then let him. If he insists on everyone else using it, then give him a big resounding 'NO'. You already have a tool that does the job, and that everyone else is familiar with; he is the one who should adapt.

It is most definitely YOUR job (with the input of the team) to specify which tools the team should use.