“Mark Said”

Let’s assume that Mark is a dominant persona in the company. It can be the Architect, the Team Leader, the Product Manager, the VP or even the CEO. When Mark says something, people align - line by line.

How many times you said in a discussion something like: “but Mark said…”, “that’s not what Mark want…”, “according to Mark…” - Explicitly mentioning the person first name, so everything you say now make much more sense, this is the clarity the discussion needed. But the discussion never ends because people are interpreting differently what Mark think, but Mark is not in the room to answer (he is busy managing a 40B$ company..), and we have no other intelligent Joker to pull off, so where should we go on from here? Is that how Mark want us to work?

What if instead of using the “but Mark said” Joker, we will treat the role of that person. If Mark is the highest rank business persona, we will direct the discussion toward the business, and if the business is not clear, let’s get some details first. If Mark is the Product Manager - we should leverage the product targets, goals, and roadmaps. To be professional is to know how to work with other roles and accepting their roles. Each role has the ownership to do the best of what it accountable on, and communication is part of any dominant role in a team.

If you are still looking for clarity and think that Mark is doing unclear decisions out of his mind, you can either complain about it, or find the path to get more clarity, not just for you, but for the entire team. Work hard to find solutions. Give up and your needs will arise in the next job you’ll follow. Is there any other workplace that will satisfy your clarity? In any exciting / innovative / dynamic workplace, you will lack some clarity, but you should strive to have just enough not to use the “Mark Said” phrase. This will assist Mark’s with his super-busy calendar to find the time to give the team the answers they are looking for.

 
0
Kudos
 
0
Kudos

Now read this

R, D and In Between

R&D stands for “Research & Development”. It is the usual term for the developers team in most companies. Yet, many companies have separated their teams to research-only teams and development-only teams. Teams that do both “R” and... Continue →