≡ Menu
Pawel Brodzinski on Software Project Management

The Team of Trust

One of my recent posts triggered Glen to start a discussion which touched, among others, processes or rather lack of them in specific situations. We went through a few cases discussing how our teams dealt with them.

As I was describing how we currently work one thing struck me: how much we trust each other when it comes to our areas of competency. When we choose development tools or frameworks I trust our devs they won’t come with something unreasonable employing “let’s try this because it’s cool” approach. When it comes to hardware and infrastructure we basically takes whatever our tech support guy advices us to. I haven’t heard much of questioning my area of product management either.

It’s like we all instantly know who’s an expert on a specific field and we just go to the guy ask what to do. On the other hand almost never decisions are made without consulting with the rest of the team. I’d say it’s easier to implement any decision when everyone is convinced to it, but I can say only for myself. I don’t know why others do the same, but they just feel an urge to do so, which is good so I don’t complain.

That is why we don’t need a formalized process which helps us to make decisions. Personally I’m not fan of processes. I’d keep things as they are as far as they go well. Unfortunately usually they don’t until you enforce some level of organization/processes/formalisms/you-name-it. Yet in small, competent team of trust you can go a long way without formalizing things around.

This is why this kind of team is such a precious thing. At least mine is. How about yours?

in: team management

4 comments… add one

  • Glen B. Alleman November 25, 2009, 5:07 pm


    I hope there's not the assumption that larger teams aren't based on trust as well. Because they most certainly are in many domains.

    I'd conjecture that you don't need formal processes because you are of the size where face to face communication can be used 100% of the time.

    Consider a domain and context where trust is paramount – Information Assurance in a defense or high security environment. And consider a distributed, disparate, and possibly layered team developing the solution. Trust is mandatory but face-to-face unlikely. Formal processes of Information Assurance play the role of the face-to-face. These processes also play the role of assuring trust in the absence of specific people.

    Your personal support of process likely is supported by your business domain and context within that business domain. We provide program control services for a multi-billion $ upgrade of a US DoD branch's "every over IP system around the world." Absolute trust of the products and services used to integrate the solution and the people doing this work is provided by the process.

    This is why the "team" (many dozens of subcontractors) is a precious thing.

  • Pawel Brodzinski November 26, 2009, 3:54 am


    No, by no means I've tried to say trust is limited to small teams.

    But coming to our old discussion below one of your posts it's much easier to build team of trust when there are 5 of you than when there are 50 of you.

    And trust itself also have different "levels." When I had 20 people in development team (and this was only one of few teams led by me) this relation was much looser than it is now when the whole team is much smaller.

    And the thing that differentiates small teams from huge ones when it comes to trust is that small team in many situations can base on trust alone – huge team will need some level of organization (processes, practices) to support or sometimes replace trust.

    But yes, considering your domain, if you send a guy out there to the space he must trust that tens thousands of people did their job well even though he haven't seen them at all.

  • Fernando Alvirez November 26, 2009, 5:11 pm

    I agree with your view, Pawel: my idea too is that (especially in small teams) trust is better than the rigid structure boss/employee. however: "Trust is good but control is a must!"

  • Pawel Brodzinski November 27, 2009, 1:37 am


    We use to say: trust, but control. However software development process is pretty self-controllable. Development verifies design. Tests verify both of these. Acceptance tests check alignment with specifications etc.

    That's why when you trust your people you don't need much control. Of course the relation changes significantly between team of 5 and team of 50 – I've mentioned that in previous comment.

Leave a Comment