The crucial step most IT teams miss
When I just got my undergraduate and landed my first job as a requirements engineer at an IT company I often made fun of stressed managers. “Not able to sleep because of a project? Pffft, it’s just work, leave it behind when you go home!” Karma is a bitch though, and when I got my own team to lead 4 years later I spent many a sleepless night worrying (how productive!) about my inability to align our main project and simultaneous transition to scrum. My team, that just kept expanding, was struggling to meet our deadlines. Developers were frustrated with each other and with me and the other product owners and project managers. The product owners were constantly at odds with each other as well. Clients were complaining. It was exhausting, for everyone involved. And today, I can’t help but wonder how much difference it would have made if I’d known back then what I know now.
What do you *really* want?
Oftentimes, IT companies are oriented around productivity. Achieving a high velocity, building tons of features. The teams are teams, sure… but even more than that, they are separate people, each trying to do their best work.
But that’s good, right? Yes. And no. Let me give you an example…
Imagine a bike. The product owner decides: this month, we’ll need a prototype for the bike. Requirement engineers describe the different functionalities of the bike. The developers divide the user stories: one makes sure the bike can move forward. He designs the wheels, the pedals and the mechanism between them. The other is responsible for safety. She designs the brakes and lighting. The last one is responsible for comfort, designing a comfortable seating and grips. In the last week of the cycle, there’s a problem with the brakes. Unfortunately, the other developers are still working on their own features and don’t want to abandon those. They want to finish their own work first. The result? A fast and comfortable bike with lighting and brakes that fail half the time.
Unfortunately this happens every time when a team is a group of individuals rather than an actual team. When individual results are more important than the team result. Rather than making sure of the best possible group outcome, team members focus on their own tasks, playing the blame game when the final result doesn’t live up to the expectations.
We all know the manufacturing concept of a bottleneck: if one part of the system isn’t aligned, it influences the whole system. But when it comes to teams we don’t invest nearly as much as we should to fix these bottlenecks.
Do you think this only happens at team level? Think again! How often do companies fail because the marketing is done brilliantly but the operations are struggling? How often do we see managers fighting over budgets, each eager to obtain what’s best for their team, without paying attention to what’s best for the business?
Moving forward, together
If you can relate to the issue I describe above, I’m happy to tell you there’s a way out. This way is what most companies claim to have and very few of them actually use: the company’s (and/or team’s) mission and vision.
Whenever a team needs to make a choice, there’s only one question you need to ask yourself that should be leading: “Which option would help us most to achieve our mission and align with our vision?” This goes for development teams — what do we need to do now, this very day, this very moment, to help us achieve our team mission — and leadership teams — how can we divide resources in the best way to achieve our corporate mission — alike.
And this brings us to the crucial first step that’s so often overlooked with IT teams: defining the team mission and vision. What does the desired outcome look like? What does it take to get there?
This is not as simple as it sounds. After all, it’s easy to write something down, especially if some coach tells you to do so. But ask every team member what the mission and vision means, ask them to explain its influence on their work and you’ll discover a bunch of misunderstandings and misalignment.
That’s why the best teams take time to make sure everyone on the team understands the mission and vision. And gets behind it.
Yes, it takes time. It takes effort. The results are less instantly tangible than writing code. But I promise you this: once you have a team where everyone is aligned on the common results, you’ll not just see an increase in productivity. You’ll see an increase in progress.
After all, successful teams aren’t successful because they have the most productive individuals. They’re not even successful because they have productive individuals with amazing communication skills. They’re successful because they do whatever it takes to reach the team goals. And they do it together.
