Here @Solid we strive to change the way people meet, work and collaborate during meetings by prepping attendees before a meeting, helping keep things focused on the agenda and providing actionable summaries only minutes afterward. Oh, and it works with Google Apps, Evernote & Slack and some other cool apps you use everyday.

The only way to run effective and actionable meetings is to follow these 7 essential rules. So why don’t you use this manifest to decorate your meeting room and widespread these best practices among your team?

Download your A4 version Here

You’re probably wondering what is the 7th rule… Try and use Solid, the app for 100% productive and actionable meetings. Get access to the beta version by signing up now. We’re letting in new users every week.

 

Tons of articles are published every week about workflow automation, time optimization and productivity at work. At Solid, we love digging through all that content and extracting the best every day.

Read below how Mattel fired their precedent CEO due to ineffective meetings. Discover all the tips and tricks that we have gathered for you to run 100% productive meetings.

Getting serious about your meeting problem

This is NOT a joke. Do you know the story of Bryan Stockton, CEO of a billion dollars company that recently got fired because of bad meetings?

Here is the statement of the WSJ’s article only a few weeks before the announcement:

Decisions on everything from marketing to product features dragged on through multiple sessions — often with no final decision being made. Employees would spend weeks putting together elaborate “decks,” or PowerPoint presentations, that could run to 100 slides or more, detailing the minutiae of every upcoming product for a brand and every facet of a marketing campaign.

Bryan Stockton tried to make some efforts. He had recently issued an edict to “speed up decision-making and free up executives by putting rules around meetings, including none to be held without a specific purpose”.

But it was already too late…Chief Executive Bryan Stockton had to resign a few days ago.

Prepare yourself … and others

Of course, we are all well aware that it is important to get prepared before running or attending a meeting. But if you want (trust me you’ll want) to avoid some endless “brainstorming fights”, especially when tackling thorny issues, you’d better prepare others for what you’re about to say.

Every so often, controversial topics must be discussed during a meeting. To sidestep potentially unpleasant reactions, hold a few one-on-ones with your most outspoken or influential team members to gauge likely responses.

says Marty Fukuda,Chief Operating Officer of N2 Publishing.

“Give every meeting a ‘Parking Lot’ “

That’s a powerful piece of advice from Craig Cincotta, Vice President of Brand Communications at Porch:

What do you do when you are in a meeting and you go way off topic, but the discussion is a good one to have? Put the idea in the “parking lot” and make a commitment to revisit that idea at a later date.

Don’t Waste those “30 minutes Gaps between Meetings”

We all have 30-minute gaps in our work schedules that we neither planned nor agreed and they may be the key to turbocharging your productivity. Just identify those gaps beforehand and plan some simple tasks, that could save your day according to Jordan Cohen in this Harvard Business Review article.

Four 30-minute gaps in your schedule can add up to 25% of your day.

Try Solid

Solid promises to change meetings, by prepping attendees for a meeting beforehand, helping keep things focused on the agenda, and providing actionable summaries only minutes afterward. It works with Google Apps, Evernote & Slack.

You can request your private beta access >>Here.

Try some or all of the tips and let us know if you see the change ?

What if we told you, you’ll be able to synch Solid to the apps you use daily? Awesome, right?
Well, we’re thrilled to present you 2 brand new integrations to Solid today: Slack and Evernote.

Also, don’t forget to sign up to Solid’s beta if not done yet, we’re letting in new users every week.

Solid lets you take notes before and live during the meeting, and mark them as tasks, decisions and open issues.
After the meeting it’s super easy to share the minutes with all the attendees: 1 click on your end and they get a recap email.

Sharing with others is great to know exactly who must do what and what the action plan is. But you might need to add your own tasks to the apps you use daily to get organized. Check out Evernote and Slack integrations.

Evernote Integration

You can now export your meeting minutes to any Evernote’s notebooks. Just click on “export to Evernote” when you’re on the page of a meeting in Solid, choose your notebook and… it’s done. Your minutes are automatically formatted with your tasks & decisions.

Slack Integration

If you & your team are using Slack you may want to share some meetings minutes to a specific #channel. It’s a great way to involve other colleagues without asking them to take part in every meeting.

Just click on “export to Slack” and choose the appropriate channel. It will automatically be published as a formatted post inside the channel.

Don’t forget to request your Private Beta access >> just here and tell us in the “comments” box what other integrations you would be interested in.

 

We work hard at Wisembly to optimize business meetings. Practically every time we develop a new feature, we imagine a way to measure it. Indeed, it is key for us to have a detailed vision on a user’s or a team’s habits before we can give pertinent advise to run more productive and actionable meetings.

Our new product, Solid is the solution to 100% productive meetings ; you just synch it to your agenda and get access to the overview of your meetings habits (average meetings number, time spent, percentage of meetings organized, etc.).

It was quite obvious we had to take a look back at our own habits in meetings at Wisembly.

So when launching the very private beta within the team in December, the first thing we decided to do was to analyze a total year of meetings at Wisembly.

Here are the results when we compared all the team’s Google agendas, 2 months ago.

Last October, we offered a survey to 500 people to analyze their habits in meetings ; see the details just here. Guess what was the average number of meetings for these 500 per week? Six. To be honest, we thought it would have been higher…

It seems that the Wisembly Team is quite above average with 9 meetings per week.

30 people are working at Wisembly today, the startup has doubled it’s size within a year. As a co-founder, I believe that change in the team structure and the rapid growth of our company has definitely created some unnecessary meetings at some point.

Also, I have a few other reasons that explain the higher average number :

• Most salespeople will count their clients’ appointments as a “meeting” in their agenda.
• Salespeople, Marketing, and HR naturally have lots of meetings with external people, due to their core mission: help the business grow.
• The Product Team, Developers, and the Office Manager mostly make progress reports or project reviews, specific types of meetings: it would be interesting to record them differently in the future.

It was quite interesting for us to have a closer look at 2 pieces of data :

The “number of prepared meetings”

It is based on whether or not the agenda was sent to participants prior to the meeting. Only 33% of our meetings are actually prepared and we have immediately highlighted the point and asked everyone to make sure they upgrade that figure within a month!

Work expands to the time you schedule for it

Remember the Parkinson’s Law? Not so many people think about changing the duration by default of a meeting on Google Calendar (1 hour). And it has thus become a bad habit for many to run 1-hour meetings. It is important to fight this bad habit and adapt the timing to your meeting every time.

Last update: we have been using Solid for 2 months now, what has changed?

After 2 months of Solid’s use for the Wisembly Team, we can already see some interesting key facts:

Well-prepared meetings last only a minute longer than expected, whereas poorly prepared meetings last 9 minutes longer than expected.

Teams are now more careful to setting initial meeting lengths (take-away: forget the default time proposed by your agenda provider).

We’ve said it already, meetings are not dead, they simply lack process and monitoring. In just a few months, you can see how we can still advance and optimize certain numbers to be more productive.

Are you surprised about the results? Well, find out yourself: we’d be thrilled to count you among the community of Solid’s beta users. Also don’t hesitate to give us some feedback in the comments section!

Here @Wisembly we strive to change the way people meet, work and collaborate during meetings. We come from a Symfony2 / Backbone.js / socket.io world with our event / training / conf call products, and when it came to thinking about our next product, Solid (request beta access here!), we slowed down things a bit and looked for a different and a better way to manage our frontend application.

We looked at Angular.js and Ember.js that were trending among cool kids out there and that looked both promizing for us to manage an ambitious javascript application with our growing developpers team (by the way, we are hiring!).

After doing the famous Todo MVC example and some other POCs, we decided to go for Ember with Ember-cli.

Here is our humble 3 months real life Ember.js feedback for Solid, what we have learnt, what we think is cool, what is really uncool and what could be improved.

Ember.js

Convention over configuration

First of all, what we struck us is that Ember is not like Backbone. It’s a strongly opinionated MVC framework.

That means devs accepting to embrace Ember’s philosophy will be rewarded by the framework after the learning curve, whereas more skeptical ones will keep on fighting against concepts they may consider odd and won’t unlock the true framework potential. But hey, nothing new here, that’s the same for every opinated framework in any language.

Using Ember conventions and components will allow you, once masterized, to scale only your business complexity part inside your app with your growing team, instead of handling framework complexity and improvement (rendering, syncing data for example).

We observed that, even in a short 3 months long period window, we took 2 sprints of 2 weeks to set up our application foundations with 2 javascript developers and then handled in the last 2 sprints more features with only one dev that we would ever do with our current Backbone production application. Integrating an authentication mechanism? There’s an ember-cli plugin for that. Integrating Google analytics, in our app? There’s an ember plugin for that too.

It feels right to see in this javascript world with Ember the same benefits we experience with Symfony2 for a long time now with bundles and plugins that perfectly fit, that are easy to install or to maintain, thanks to the framework rigor and conventions.

What does that mean for your team and your productivity

Good points

• Your developpers will tend to produce more homogeneous code. That’s a great thing for productivity, maintenance and scalability
• New team members will already know Ember and will understand your code faster, they’ll only have to look to your business code, no need for them to read and learn a framework related mechanism you could have developped inside your own framework
• You won’t have to maintain core parts of your code. Just keep your project Ember-up-to-date to benefit from the latest community features and improvements. Again, no time wasted in maintaining something a community could maintain for you.

Risks

• What happens if you integrate an Angular dev or a Backbone dev? Despite the fact that Ember and Angular differs in many ways, their root concepts are not that far, and the new “dev on the block” should feel at home within days (1-2 weeks max)
• You should consider understanding and using “the ember way” to do things, before trying to customize or monkey patch them => think about tests, future upgrades, and glitches you should introduce in the app because “Hell yeah, I like to customize ALL THE THINGS”

The world is made of components

Do you embrace DRY methodology? Components are your new friends

Ember.js allows you to wrap all of your repeated pieces of code inside components. Whether you have repetitive templates chunks, or UI elements, or event entire parts of your app, you should consider using them.
Don’t fear using components in components, the more “organic” your design / approach is, the more modular your components would be.

Another cool aspect of using components as a front-end developer / UI developer is to list UI oriented ones in a styleguide and, in that way, help developers to test, see regressions and find which ones are available with their parameters.

Ember 2.0 will put even more emphasis on components!

Not very cool points

Before digging deeper into Ember, we heard about its famous “learning curve”. Some said it is like climbing a mountain, some compare it to a roller coaster. We tried and we must admit, it’s pretty heavy and almost sinusoidal, but really worth to surf.

We’ve had bad days and good days. We’ve had questions and we still have questions…

The first of these questions is about Ember Data. It’s an awesome library, no doubt about it: well documented, very active, and strong / stable enough for what we want to build.
But the fact is that our APIs are not fully compatible with it: not fully “JSON API” compliant, and not very modifiable, since they are shared accross our products. Since Ember Data is not very permissive, we’ve had some headaches. That’s why we are wondering if we shall build our own data store/cache/api layer.

In some cases, we still wonder where is the best place to do things and how to do it.
For example, let’s say you have to implement a global notification center for your app: we’re still investigating and iterating to find the best way to do it… Even if a “service” is what sounds like to be the best idea, it is not as simple as it seem…

How does it interact with push events (we make a heavy use of socket.io ? How does it interact with the “bubbling” of Ember actions ? What if a component has to notify the app of its state ? What if you want your models to auto-notify the user when they are saved / errored ?
We implemented all of these behaviors but we are not very sure if we did it the right way, and trying to find better methods every day (ok, finally it’s pretty normal for devs ^^)

Maybe the “convention over configuration” is not for everyone, and not perfect for every cases. It might be sometimes inevitable to patch or get around things for your business needs and Ember “rigidity” will be more a burden.

The way components communicate through actions is still very perfectible (notably the sendAction() method, which could be very confusing for beginners)

Ember cli

COOL points

The coolest point about Ember-cli is its EcmaScript6 transpiler, clearly. It’s really cool to write imports without requirejs headhaches and to be able to use ES6 features, right now.

Besides, it provides a full development environment with server, automatic incremental build with Broccoli, live watch and reload, tests & jshint.

Ember cli is bundled with lots of cool generators following “blueprints” rules that allow you to keep up a good workflow (create the right files, at the right place, create the corresponding basic tests, etc…). There is no way to make a mistake when using generators, which is a very good point for scaling (product + team). Blueprints can be created, so every team can reproduce its own workflow

In addition, Ember-cli brings its own resolver that provides/allows a way better file architecture (PODs are also possible)

A gift in every new version!

The version we are using (0.1.2) brought “Content Security Policy”, which is a cool addition if content security is important for your app, and the browsers you target are not yet compatible.

Version 0.1.3 will let you create multiple sets of CSS files. To start with, we’ll try to use it to target specific needs (mobile, desktop, and why not old browsers). We can’t wait for the upgrade (but after the beta has launched ^^)

Not very cool points

Despite, Broccoli has really cool sides, the Brocfile is a bit complicated, and our frontend team is a little reserved. This lacks some documentation too…

In addition, Broccoli looks like to be quite slow and less flexible compared to Gulp: the fact that it recompiles everything, including JS even if you change only a line of CSS is not good at all.
Thus, CSS is too long to be live reloaded and there is no CSS injection (but it might change very soon => see issue #2371 on ember-cli repo)

To finish, the upgrade process can be a real P.I.A (this is a very very perfectible thing)

Handlebars

Cool points

Handlebars is fully focused on templating, with just a bit of logic (making it very easy for HTML guys to use and understand). For more logic, use controllers!
Latest version made a great step towards more performance (those ugly metamorphs Dudes have disappeared) and version 2.0 / HTMLBars promise to manipulate DOM elements vs strings (as with handlebars)

Not very cool points

Logic is very limited here. Okay, right, 99% of the logic should be made inside controllers as we said above, but sometimes we lack some tools and logic features to handle presentation logic that have nothing to do inside our application code, our models nor our controllers. When we say that logic is limited it is even a AND or OR condition in a if statement that is not possible. In fact, controllers are currently more “presenters” than controllers because they embed both application logic and presentation logic.

Ember Data

COOL POINTS

Ember Data comes with various adapters for multiple usage ways (Want to use fixtures? Use fixtureAdapter. Want to use firebase? Download the firebase adapter, configure and run with a great smile, otherwise stay with the RESTAdapter)

It also comes with various methods to easily manage models and records

We particularly like records flags (isNew, isDirty, isSaving, etc….), it’s a fantastic feature !

Not very cool points

Ember Data is very opinionated (too opinionated?). No option could be passed to save() and other methods, virtually impossible to extend.

For instance, pagination is still an issue for us today (hopefully we didn’t have to deal with it at the moment)

Ember Data follows and implements JSON API standard, but partially! So we had to do a lot of monkey patching (will apply to you if your API is not 100% ember-data compatible)

We also had problems with socket.io, we still have questions like “updating a model that is not already in collection?””

We’d really like to have some time soon to look to that more deeply and consider not using ember data and find / create a data layer more modulable.

Internationalization

We tried ember-i18n that was a good start but did not embrace fully gettext philosophy. We had a look to Jed, i18nnext or format.js but there were too complex, shipped too many unecessary features, or did not follow gettext standards. So we came with our own tiny plugin ember-gettext. We’ll make in the near future a more complete post about internationalization and gettext / Poedit standards and phylosophy.

Tests

We clearly did not had time to dig deeper the tests more than in the docs, we’ll fill the gap once the beta opens.

Ember Inspector

A ~~very cool~~ mandatory chrome plugin to help you debug your ember.js app.

Review your views / routes structure, check the loaded data in the blink of an eye, analyze the rendering performance, find everything in your container, etc…

The runLoop

Understand it will make your life easier (it can bring peace to the world too..)
More explanations here

Conclusion ?

When we begun our POCs (angular.js VS ember.js), all the hype around Angular were telling us to use it. We really liked Ember.js and its philosophy. It was more “us”, coming from backend for some of us from Symfony or RoR. We liked the robustness of Ember in the shadow of Angular fame and glory.

We are very happy with it at the time we write this article, and the future seams quite bright to, Ember.js 2.0 looks as cool as the next StarWars trailer.
Check the road to Ember.js 2.0 and the discussions about it on HackerNews.

Ember.js really feels like something strong, complete and SOLID, which happens to be a perfect match for the apps we want to build now and in the near future.

If you liked this blog post, please register to our solid beta and next week challenge us on our application. And maybe during this process, our product will help you organize even better scrum meetings!

How many hours have you lost in unproductive meetings? Do you think this could have been avoided?

Definitely!

At Solid, we make your life easier and help you run away from endless meetings.

I bet you want to spend less time in meetings, come join the Solid Beta

Over the last several years, a bunch of applications have tried to kill off the idea of going to meetings. 37Signals, Slack and Jive have all promised a world where meetings would be a thing of the past, completely replaced by real-time, virtual interactions.

Sorry, but that’s not going to happen.

Increased information flowing around businesses means more communications within teams. Thanks to these brilliant tools, most employees now have access to more information than ever. So it’s hardly surprising that, if teams communicate more among themselves and have access to more information, they have more ideas, more projects - and of course, more meetings.

According to a study published by Bain, 15% of a company’s total time is spent in meetings. This proportion has increased regularly since 2008. In 2008, Yammer and Asana had only just been launched, Podio and HipChat didn’t even exist and Jive was in discussion with Sequoia to raise $12M of Series B funding.

Meetings: building trust within your team

People instinctively need to meet face to face to move faster and make decisions.  In meetings, we can truly see through people: understand their body language, receive smiles from our teammates, say funny jokes and in the end we create unique relationships.

This link is essential to solve a problem, go forward with a project and have confidence in the people we work with.

Business developers like to meet their future customers, head of states need to meet their peers and teams need to meet others regularly.

Today people communicate more but have less confidence in each other; this is due to the digitalization of communication and the unstable economic we live in. We need more than ever to re-establish trustful relationships in our companies.

How to get there? Meetings.

We run the meetings we deserve

There are no worthless meetings, there are only bad managers.

We have to learn the art of holding a successful meeting. There is a theoretical basis to be learned. Below the basic rules we don’t learn in school:

• Naturally, meetings need to be prepared in advance, have a clear agenda and minutes must be taken (and actioned) immediately following the meeting. Let Google’s rules inspire you!
• Don’t use the default meeting length provided by your calendar tool. A meeting shouldn’t last an hour just because Google Calendar told you so. Often, just fifteen minutes is enough.
• There are times when organizing a meeting is never the right thing to do. If the goal is simply to share information, enterprise social networks are sufficient. Simple ‘alignment meetings’ of this kind can be toxic.

Meetings: an incredible opportunity to innovate

Well-executed meetings are fundamental to enterprise success (but everyone still hates them anyway). It is the last area of professional life that remains untouched by innovation and data gathering. Nothing has happened since the invention of the projector and the launch of PowerPoint presentations. However, the potential for innovation is huge.

Some genuinely cool examples:

• Clara: a virtual assistant who plans your meetings
• CharlieApp: an app that introduces you to the social network profiles of the people you’re meeting with
• Gridspace: a box that records all the discussions in your meeting in HD
• Solid: generates minutes of the meeting shortly after the end of the session.

We are going to be spending more and more time in meetings. Let’s use the right tools to ensure that our meetings generate more business instead of destroying our productivity.

If you want to take part in our beta test, we will be delighted to welcome you on board.