Skip to main content

How NOT empowered teams work

 

In "Empowered" Marty Cagan described how the best teams work. This way of working is challenging, but a reachable ideal we should all strive for. However, while on the way, we often find ourselves in less than ideal conditions. And sometimes, when we really unlucky, our ways of working might be in total opposite to the empowered ways.

I thought it might be "fun" to describe how NOT empowered teams work.

First of all, you're not a team. You're just a group of individuals that been told to work together. You don't really know or trust your "teammates". You all have different bosses and agendas. Also, you don't sit together because why would you hang out with engineers? 

Then one day you're summoned to an executive's office. He says there is a critically important "thing" he wants you to deliver. He says the future of the company depends on this "thing". You need to drop everything you're doing and immediately start implementing the "thing".

You don't want to ask questions about the "thing" you now need to deliver because you don't want to look stupid. You channel all your creativity and turn those few executive’s words into "user stories".

You have no idea who your users are, you just learned in your CSPO course that every story should start from "As a user". These words mean nothing to you or the engineers you're working with.

Speaking about engineers. You drop a sudden meeting bomb to "refine" the "thing" you'll be delivering. People show up late or not at all. For several hours you try to squeeze out the commitments from the engineers. They refuse to give you a date the work will be finished, asking more and more questions you cannot answer. Suddenly the meeting ends and you realise you'd have to guesstimate yourself.

The work begins and every day you meet for a standup with your "team". One by one, engineers say what they did yesterday and what they gonna do today, but nothing moves on your board. At the end of the sprint, none of the stories has been completed and you're forced to move them to the next sprint.

On the retrospective, you ask your "team" why the work is going so slowly. They blame unclear requirements and lack of design skills in the team. You say you'll fix the problem and involve a designer. You go to the design team manager and ask to assign someone to your project. Next thing you know - the scope of the project doubles when a new design is created.

You're stressed as now you have to face the executives and tell them the "thing" they want will be delayed. You suggest cutting the scope to be on time or moving the deadline. But you learn neither scope nor release date is negotiable. Oh, and the thing should be of the highest quality as well. Remember - it's the most important "thing". 

You return to your "team" and say they now have to work overtime, possibly on weekends. This doesn't speed things up, only now everyone blame the next person for not doing their job. The already tough atmosphere in your "team" becomes hostile. 

The release date is approaching and you're making an executive decision to ship the "thing", no matter the state it is in. Your testers report numerous bugs, but you say those could be fixed after the release. You repeat to yourself that what you're building is an MVP and it's fine for an MVP to not be perfect. 

Finally, the moment of truth arrives - the release day. You arrive in the office with a pack of doughnuts to reward your engineers for delivering the "thing". They don't have time to eat them as the release failed. You're running around and shouting like a madman demanding everyone to focus on the release. 

Other PMs come to you saying your release broke their products and customers already calling support to complain. You say it should be fixed "very soon". But your "team" had to stay till late in order to finally make the damn "thing" work. From home, you send a celebratory email about the successful release. 

The next day you're eager to learn how the new "thing" performs. You ask engineers but they just shrug their shoulders, it appears you forgot to request the tracking for the "thing". You rush to write an urgent story about the tracking but it's hard to define as you don't know what the "thing" should achieve. But you need something to show executives so you come up with metrics so generic they could mean anything. 

Comes the day you were waiting for, the day when all the hard work will pay off, the day you will showcase the "thing" to the executives who requested it. Arriving at the meeting you're dreaming about all the shiny things you'll buy with your inevitable bonus for the stunning work you've done. You're nervous, your time under the sun approaches. 

- That's all we have time for today, - you hear from executives and the meeting is over. 
Confused, you're approaching the executive who requested the "thing", but he's busy with the most recent "most important thing" and the new PM who's trying not to look stupid and ask questions. 

All you want now is to go to a bar and moan about everything, the executive, your "team", the "thing", everything. However, everyone is busy today, you notice no one wants to sit next to you at lunch or eat your doughnuts. 

Popular posts from this blog

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions . But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

7 steps of Product Discovery

Before building a product - how do you know what product to build? While building a product - how do you know what features are the most valuable? After you've built a product - how do you know if to tune stuff or add a new one?

Fogg Behavior Model

Have you ever wondered why you do certain things? Why are some behaviors easy and joy to do while other not so? And your customers - have you ever struggled to understand their behavior? BJ Fogg , from Stanford University, has created simple and powerful behavioral model for persuasive product design.