Marvellous question! The first port of call is whether you trust the people. People have to earn trust and prove their competency not just to their employers, but also to their co-workers. I don’t have trouble trusting someone who has demonstrated their competency. If you are surrounded by people who have sufficiently proven their competency and are trustworthy, then you can look at the process. The processes are (in my humble opinion) both a way to catch and compensate for mistakes and a way to improve coordination and effectiveness in the team. Bad processes can ruin good developers and good teams, but I believe that good teams will naturally gravitate towards good processes. Processes are only as trustworthy and effective as the whole team. I always view a process with a little suspicion and I always question the processes’ effectiveness and the steps involved in it: is it as good as it can be? If the team is good I have less suspicion about the process but if the team is bad I have great trepidation about the process. This leaves tools... there are some good tools out there and some bad ones. If a good team with good process is using a bad tool then you will get bad results, but the good teams will again naturally gravitate towards good tools. Like processes, I always regard tools with suspicion: does this tool really help me in my work? If it doesn’t or I can find a better tool, then I use a better tool. Even if a tool is spectacular, it will not solve the problems of a bad team or a bad process. I've been doing some research about this area recently and thought I'd share a little of what I've learned. Ciarán