To build great software you only need two things – trust and honesty. If you have that, you can build anything, absolutely anything.
It might sound cliched or overdone, but it’s the absolute truth. I have worked with the good and the bad of software teams and what sets both apart in both cases are these two things – trust and honesty – in all facets of delivery.
Trust within the Team
As Software Managers, we all know when we’ve shipped a good release, one we are proud of, one that checked all the boxes not just for the customer but one that saw our team come together and grow. That’s the real delivery to any Software Manager – how did the team do, how did they grow, and are they ready for what is next.
The ability for a team to come together and align themselves to working together to achieve a common goal is the greatest success factor in any release. And all of this starts with every member of the team having trust and faith in each other. This, of course, is not to be confused with delegation, delegation is the assignment of tasks, trust is the better half of delegation which removes the need for it.
There is always going to be a mad sprint to get the finish line, it’s a relay race, one person can’t do it all. If one person can’t get the baton to the other and trust and believe that the next person is going to run just as hard as they just did, you will fail, always.
Here are some examples of teams that are implementing Software Built on Trust;
- The team doesn’t need to be asked to look at bugs, they are already doing it.
- Team members who finish their work early, jump on the bug pile and start taking from those that are overloaded.
- Everyone understands the problem we are trying to solve and the value to the customer that is behind it, these become our guiding principles.
- The team is not hidden from the customer, but is encouraged to go and meet with them, as much as they want – feel their pain, experience their joy.
- Honesty is paramount – did we screw up? Yes, great, let’s admit it and move on.
- We don’t muddy the waters – a feature is a feature, a story is a story, everyone follows the same sprint – if multiple teams are involved, they are all on the same path.
- When the product manager asks how it’s going we don’t say “fine” – we give them the lowdown, the good, the bad, the ugly.
- Extra time will invariably be needed, somehow, somewhere – whether it’s pushing out the release or working early/later – the key is we make this decision as a team.
- We plan to set the team up for success. If it’s a highly research-focused project, we give them the time to make mistakes, to fail, to learn, and to grow – because next time they will come back even better.
Some of this might seem obvious, others are easier to write, harder to implement (i.e., who wants to tell Sales that we had to cut their favorite feature). But if we let Sales keep thinking there is hope for that feature to make it into the release, when there probably isn’t, we’re not giving them time to adapt, change and come back to us with suggestions for what we are able to do.
Software Built on Trust starts with Development but it permeates it’s way through Product Management, Sales, Finance, everywhere the organization depends on that delivery.
Actions that Build Trust
When we think of this work, we think it’s complex, we can’t do it, it requires too much change, but it comes down to making and introducing a few simple changes into your organization and making them the key to your continued delivery and growth.
Honesty – we always need to be honest with each other and everyone we interact with
Ownership – we own it, no one else, so let’s act like we own it and treat it like your favorite thing
Accountability – this isn’t about making estimates that are off and working insanely to make them come to bear. This is about being upfront at discussions on progress and giving the bad news along with the good
Leadership – everyone leads, not the manager, not the senior developer, everyone, everyone plays this role – everyone can make a decision in the best interests of the project
Retrospection – a constant effort to always be questioning, what you are doing, what we are delivering, is it the best thing, do we need to pivot, what comes next. This isn’t about sprint retrospects, this is the daily, weekly questions that you are constantly asking yourself and others.
When you have those five traits at play in your delivery of software, where everyone comes back to them at the end of each release, build, trial, discussion, design session, and meeting, you’ve created a foundation of trust amongst you and your team. It doesn’t matter how larger or how small the team is if everyone is on board if everyone puts those traits into practice if everyone is consistently living and breathing these traits when talking with customers or any other group.
Trust within the Leadership
I left this to the end, because it’s the most important, presumably your team has a manager or a leader that has been entrusted with guiding your team. You report to them, look to them for coaching, support and guidance. They are there for you if you have a problem. If you need to discuss issues of a personal nature with them – they are there to help you.
But if you don’t trust them (and conversely if they don’t trust you), you will never achieve building Software on Trust, you will never get there. You will never achieve that goal and it will always remain elusive.
Software Built on Trust is not an element of cadence or principle that you turn on and enable. It is more than that, it is a path, a practice, a direction that you, the leader, must take and hold onto. It’s one that is defined by you the manager that permeats to the team, it’s the behaviour that you want to see happen that can only happen when you are willing to take the hard steps to show your team what it looks like.
Lead with Trust.
Want more? Check out my book Code Your Way Up – available as an eBook or Paperback on Amazon (CAN and US). Follow us on Twitter @Codeyourwayup and find out more about our Software Leadership Programs here.