Alright, it’s time to spread some positivity after the last article. If buy-in is so important for collaboration, then how do we get real clear with our teammates about our collective commitment before we embark on a solution? Here are 3 questions we should ask so we can get clarity on the problem, the effort, and the rollout of a solution.
Silos are bad in organizations that need to collaborate to succeed. Kudos for trying to break down barriers between teams, but when the other side doesn’t buy in that a problem exists, any effort you put in to fix the silo problem is destined for failure. Here’s a personal story of effort, failure, and lessons learned.
Groupthink is terrible for decision making, but dissent that make a team go around in circles is probably worse. We’ve all been a part of long meetings where no one agrees but nobody feels they’ve accomplished anything when they leave the room. Break the cycle by disagreeing without being disagreeable. Read on to find out how to dissent for a cause and to be a a great dissenter.
Do you only speak to development teams when you want something done? That's a sign that you consider your colleagues as tools rather than partners in crime. If you keep treating development teams like an afterthought, you'll find less participation, less care, and even worse, they will be rooting for your failure.
Your development team deserves a seat at your solutioning table. Bring them in early, listen and act on their feedback, and help everyone understand the true objective of what you're trying to achieve for your client. Read more to find out why this is a great idea to foster trust between PS and Development teams.
Your very first one-on-one with your team shouldn't be a soul-sucking exercise. I experienced from one of my mentors an extremely memorable and impactful first meeting, and in the process learned a very valuable lesson: professional altruism. If you're in it to help others grow, then express that professional altruism from the start.
I never had a "leadership manual" when I started leading services teams. Every team is different, but with help from my mentors I started doing 4 things when I take a leadership role: Listening for team pains, defining a team "why", prioritizing team pains to tackle, and learning and adapting to start the cycle all over again.
