The 4 Pillars of Collaborative Culture

Does everyone on your team share ideas regularly? Volunteer feedback or ask questions? Can they be vulnerable? Safely challenge even the mission?

There are 4 essential pillars to a Culture of Collaboration:

• Safety.
• Speed.
• Clarity.
• Commitment.

The first two substantially impact each other: Safety & Speed. The next 2 pillars will ensure your process demonstrates value over the near- and long-term.

The 4 Pillars

• Safety: Is it safe to fail? Is experimentation celebrated?

  • A “fail” is always an opportunity to learn & improve.
  • Do discuss & embrace when situation and/or opinion changes?
  • Leadership should highlight learnings from “rejected” proposals. Even if no proposal “won”
  • Show where root cause analysis is appropriate? (Did this not align with OKRs? Could leadership clarify or narrow goals?)

• Speed: How much time should drafting take?

  • Rule-of-thumb: ideally 1-20 minutes; perhaps max of 2 hours.
  • Speed here is about efficiency. This respects BOTH you & your colleagues’ time.
• Clarity: Do you produce clear and actionable decisions? Is the value clear to all involved? Consider value to external teams getting earlier notification, avoiding wasted effort on code the legal & compliance folks may object to.
• Commitment: Can you find the decisions you made 2 weeks ago? 3 sprints ago? If not, it wont make sense to spend much time

Teams should define their norms & expectations

Tip: Discuss and determine the best way to work as a team. Adjust as necessary.

Document your findings as succinctly as possible, for example:

• Screenshots in intro preferred for anything UI related.
• 1-line text summary preferred. (Use 1-paragraph for BizDev or New Features.)
• Mock screens in proposed solutions, before final decision’s due date.
• Make specific label recommendations: (e.g. Urgent, [Team-Name], Needs C-Level Approval, Hackathon, Spike related.)

Considerations for your Team

Take some time to think about this process, demonstrate to your team that you value an environment where their ideas are heard.

Focus on these areas:

• Set Clear & Minimal Expectations. Usually this is defined per role/division (e.g. finance, security, incident response, engineering, executive.)

  • No draft is too rough to share. (Use clear labels to indicate as such.)
  • Is proper spelling & grammar expected? (For executive proposals, sure. But security incidents might de-prioritize grammar.)
  • Are sketches or diagrams preferred? (Flowcharts could be required for Network Changes. Sales projections may be the norm in that team.)
  • Is author expected to propose a solution to problem? (Or a placeholder “straw” solution?)

• Provide Multiple Example Proposals

  • Create brief examples in each mode.
  • Use pending decisions to draw in team mates.

• Depending on the nature of your group, consider a Code-of-Conduct

  • Important if you include 3rd parties, non-employees, Open Source community, etc.

• Empathy

  • People are often anxious sharing ideas. It’s human, even rock stars get nervous performing.
  • Accommodate communication preferences & needs of those on your team.
  • Talk about this with your group (or individually) regularly. Often a quick pairing session or brain-storming can help unblock and re-energize.

Tip: Make a habit to share the proposal as soon as a title is written.

It’s ok if it’s in draft a while.

Whenever a proposal is ready to advance, bring in the stakeholders, discuss & move things forward.

As proposals develop, a backlog of draft ideas becomes a fountain of opportunities.

Are fresh ideas celebrated? Do you celebrate “out there” proposals? This will impact the value & volume of ideas.

Be intentional about modeling what you want to see.

Scope & Expectations

Whernever possible, responding to a proposal is ideally a few-click process.

Decide if you need a lengthy analysis with exhaustive notes, or a quick 1-line comment, or even an emoji vote.

Expectations should be clear. Trying to describe the level of quality by labeling documents with “WORK IN PROGRESS,” or “Feasibility Comments Requested” doesn’t usually energize commenters. Teams benefit from knowing what type of deliverable is expected.

Rejection (or the perception of failure) should never become a dis-incentive. A “culture of error” is critical here: Embrace failing faster/more often! Value a cheap & early feedback loop!

Every team will have different norms & priorities here. Try to reflect & improve your teams approach as part of retrospectives.

Measuring Success

Consider how ideas come about & evolve in your organization:

• What percent of your employees/team share ideas?
• What’s the average time before an employee’s first suggestion? Days? Months? Years?!?!?
• Does everyone on your team regularly share ideas?
• Do people feel safe? Can they be vulnerable? Even question the mission?