Optimizing and preparing a meeting Yes, you all hate long, senseless and tedious meetings that are not going anywhere. There are also well defined rules to not have those meetings. Set a purpose and goal, have an agenda, assign a moderator, make summaries, be free to leave the meeting if you are not needed and you don’t need anything from it… These meeting rules are good, but they are nothing else than consequences of people needing to reshape what most of the time is not well organized. I do believe the problem is bigger than only boring meetings. It is all about the structure of communication between the business units. Your problems are not the meetings. Your problem is the whole system that makes the meetings boring. In a previous article I was proposing between stakeholders and Product Management. a new model based to reduce unnecessary communication pains It was also a consequence of hundreds, maybe thousands, of mislead meetings. But setting up rules for meetings could maybe not be the only solution. The problem of unnecessary information is everywhere. In any meeting. In any context. Speak less. Do more When I wrote the article about the new communication model based on Blockchain I was trying to solve an isolated problem. Until I’ve figured out that it is a system problem that affects many instances. At the end, the theory was showing that by applying properly the blockchain structures to the communication between stakeholders and product managers could boost the efficiency and make less and shorter productive meetings. Now the challenge has come. How to apply this to a real environment? Making changes on the communication level of any environment open many challenges. We, as a product department, had to run several short meetings to define and set how this collaborative framework should work. By each of the meetings we got together with the stakeholders to find mostly their pains from the collaboration between Product and their departments. So, we started pointing out what went well and what could be improved on the interaction between the different business units. That give us enough knowledge to define the assets in between (what objects we interact with). The Assets One of the first findings was really interesting but not surprising: the assets in each chain were shaped by the needs of each participant on the chain mainly divided in two well defined groups, the stakeholders’s assets and the product’s assets. From the product perspective it was needed to split the assets in two different categories: 1. Ideas2. Unplanned work If you want to have good ideas you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away“ — Linus Pauling For the unplanned work we established a Service Desk where all the users could have access to report what was causing misbehaviors in any of our customer facing applications. For the development of new ideas we started using (a brutally good tool for product managers) where all the stakeholders can send an idea, that and together with product managers would be evaluated according to its business impact and the required effort to materialize it. ProdPad a posteriori The division of jobs was very well done at this point. Business jobs and unplanned work are planned to use dedicated channels. That left to Product Managers and Engineers the other kind of jobs. Internal tech jobs and changes remain inside of the product-technologies working environment. The Workflows Then was the time to start defining the workflow in between. The idea of setting up this framework is to reduce complexity and unnecessary communication between different teams. Implementing new rules on meetings does not reduce complexity on the system but on the meetings. If the whole structure is not working fine, the problem remains the same. And we didn’t want that. We aimed to reduce complexity on all levels. How could we implement a process where we have different business units, with different needs and different requirements? Opening dedicated communication channels? Setting structured meetings? No, thanks. It will end up in a new mess. We had to start implementing System thinking tools. In this particular case . Feedback Loops Setting loops can be one of the most challenging tasks ever. The task to keep people motivated, on board, with the mind-set to move forward but also with the desires to take a look back and point out the mistakes can be hard to achieve. And fellows, there is only one way to make that… Be transparent Show them what are you trying to achieve, their spot on the chain, how much valuable is the collaborative work and how this could have a positive impact on the development of the whole business.  For that we create 3 different loops with different frequencies where we show everything that is being planned together, what is really happening in Product Development, how we can influence the work of each business units. 1. Once every three months with one accountable person per business unit. On this meeting we will discuss goals and objectives. not in the mood “i-will-let-you-know-what-we-will-do” but in the mood “let’s talk about our goals and what is the best to achieve them”.2. Once per month stand-ups to keep tracking of work in progress. Also plan in progress.3. Once every 6 months to make workshops and trainings to learn from each other. Well structured meetings of course. Smart Contracts Until this point most were defined the Network Participants, the Assets, the Transaction Flow and the Channels of the whole model. It was only missing the Smart Contacts, that is nothing else that the behavior users agree to follow on this collaborative framework. All this process was built together with the different business units. The whole framework was established on a co-working environment where all of the parts have agreed on how to act responsibly. So, defining the smart contracts was just a question of collecting all the information we were working with and set protocols to satisfy the needs of each collaborator. Period. Ready, set, go! The main modern pillar of progress in product development is transparency. Setting up transparency in all the communication channels is vital for the development of any product in any kind of approaches. Here are some advantages of setting this collaborative framework are: More transparency between business units. Collaborative planning and shared knowledge. Less complexity communication a.k.a less unnecessary meetings. Standard and refined communication channels. Less last-minute changes. This can help to improve the working processes and have an impact on the relational behaviors of any company by creating a common language. Once this is properly implemented, the companies can reach the level of shared knowledge at most levels and between different business units. What next? Thanks for reading! If you enjoyed this story, let’s discuss about it and before you go click the clap button and share to help others find it! Also feel free to leave a comment below.Here is my Twitter Profile .

Flow

Chain

Twitter

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Boring Meetings? Part I

Too Long; Didn't Read

Company Mentioned

Coins Mentioned

Robiert Luque

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Boring Meetings? Part I

Too Long; Didn't Read

Company Mentioned

Coins Mentioned

Robiert Luque

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES