Wiser Blog: Ideas and Tips to Be Smarter at Work

Company blog from Wiser, the New York-based startup on a mission to help you and your team get more insight out of less information at work. Ideas, tips & more.

4 Easy Concepts to Make Your Team Smarter

4 Easy Concepts to Make Your Team Smarter

At Wiser, we face all the challenges of any group or company. We have multiple teams that need to coordinate, cooperate, and communicate effectively to help our clients and build our product. We have a mission to fulfill, but our roles compel each of us to prioritize things differently. As the company has grown, we’ve tried to consistently incorporate new ideas to improve our workflow and ease friction. Many of these are simple concepts that have become part of the team’s daily lexicon, things we can quickly reference in the midst of a chat or meeting to help move things forward. In short, they help us communicate faster and more effectively.

Here are a few concepts we’ve been using recently to help make our team smarter.

1. 30% vs. 90% Feedback

We’ve long admired the folks at 42Floors for offering simple but powerful ideas for improving how to get work done. Jason Freedman recently outlined the concept of thirty percent feedback in a blog post that quickly trended on our Wiser feed. The full post is certainly worth a read, but in brief:

When we’re working on a project, it’s crucial to get constructive feedback. Often, however, we aren’t about the kind of feedback we’re seeking. Is our project thirty percent done, and we’re interested in a broad conversation about the direction we’re taking? Or do we consider it ninety percent finished, and need detailed feedback on the little details that will provide a final layer of polish? Clarifying exactly what kind of feedback will be most effective for your stage in the process lets the person reviewing target their comments.

On our team, we find this practice gets the person asking for it the most useful feedback, and allows the person giving their input a clearer sense of how they can help.

2. Checklists

Atul Gawande, a surgeon and journalist, wrote the 2009 bestseller The Checklist Manifesto about how simple checklists can dramatically improve flight safety, medical care, business processes, and other complex team endeavors.

Not surprisingly, we think creating and delivering best-in-class software to high-performing teams and companies is itself a pretty complex endeavor. From testing new product features to preparing for sales calls, we rely heavily on checklists to make sure we’re performing to the best standard as often as we can.

If adhered to, checklists can create added accountability for completing tasks accurately, though Gawande thinks they need an extra element to really be effective. He suggests creating a policy in which any member of a team, even the most junior, can challenge any other member of the team for not adhering to the checklist. Empowering your team to point out when proper processes aren’t being followed helps ensure everyone is held to the same standard and fewer steps are inadvertently skipped. The result is more consistent  execution for your business, flight plan or surgical procedure.

3. Calibrating Feedback

A few weeks ago, Jeff Weiner, CEO at LinkedIn, wrote about how senior people often inadvertently create problems without realizing it by giving casual feedback. He explained:

“[O]ftentimes what I thought was a take-it-or-leave-it remark would create a massively disruptive fire drill. Up until that moment, I had no idea my opinion was being weighted so heavily.”

While Wiser is a much smaller company than LinkedIn, we still notice this dynamic and think Weiner’s prescription for avoiding it is useful, even in the context of cross-functional teams where collaboration rules and traditional hierarchy holds little sway. When reviewing a project, points of feedback that could have outsize impact are qualified in three categories: One person’s opinion, strong suggestion, or mandate.

If someone on the team disagrees with something but doesn’t feel strongly, and their point is being considered by the team, they can qualify it as one person’s opinion. This helps relieve the team of weighing it too carefully. If the disagreement is felt more strongly, the person can qualify that they see their input as a strong suggestion. This most often occurs when they are a stakeholder in the decision, and will feel its impact more directly. Finally, when a manager views an outcome as having a potentially seriously negative effect, they will mandate that their view be followed. This is the so-called “nuclear option” that should be rarely used. In Weiner’s words:

“Issuing mandates when it makes sense can pay huge dividends by enabling the company to avoid prohibitively costly mistakes. However, issue them too often or without the right justification and there is no faster way to signal your lack of trust and demotivate the team. Try to use this category sparingly (if at all).”

4. 5-Why Analysis

The 5-why analysis (or simply, 5-whys) is a concept developed at Toyota to help avoid mistakes and improve processes by uncovering the root cause of a problem. Identifying the root cause of a problem is important because it saves you and your company from wasting time with an ineffective solution by rooting out the false assumptions and other logic traps that very often cause problems. In short, the 5-whys helps increase the odds that the solution you apply will effectively prevent a problem from happening again.

There are many diagrams to help put the 5-whys into practice, but the basic concept is as follows:

  1. Identify the problem.
    e.g. A special database integration we undertook for a Wiser enterprise client took several days longer to complete than we expected, i.e. we missed our deadline.

  2. Review the problem and ask: why did this happen?
    e.g. Because our initial estimate wasn’t accurate.

  3. Review your answer and apply the same question: why?
    e.g. Because we didn’t take into account how long it would take to integrate with their database.

  4. Repeat again: why?
    e.g. Because we thought their database would follow certain standards.

  5. And again: why?
    e.g. Because we didn’t ask the client if their database conformed to our expected standards before we provided the estimate.

In the example above, the root cause we’ve identified is an assumption about the project we undertook that turned out to be false. In this instance, developing a simple set of questions to ask in advance of future integrations will help us provide a much more realistic estimate and thereby hit our deadline.

The 5 steps in the process is an average number of steps typically required to arrive at the root cause of the problem, but more steps can be necessary. For more on the 5-whys, Karn Bulsuk, an Australian-based management consultant, has some great resources on his blog.

Nathaniel Emodi heads up business development at Wiser, the private social newsreader for teams, companies and organizations.