Need to connect a Freenode channel to a room in HipChat? Or want to give customers a simple way to connect to a channel in your Slack team?

Sameroom does that!
Learn more

 Subscribe via RSS

Tag: philosophy

Startup Death Zone

By Peter Hizalev

The metaphor of climbing a mountain is often used to describe the struggle of building a business. I want to take this metaphor a bit further. In high altitude mountaineering, there is a concept called the Death Zone. As climbers move up a mountain, they eventually reach an altitude where there is so little oxygen, any unplanned stay will result in disaster—thus the Death Zone. This altitude is not an absolute number: it may depend on the distance from the nearest camp, the amount of climbing infrastructure installed along the way, and so on. The key is to carefully plan the entry and exit from the Death Zone, and to focus on minimizing the time spent there. To do this right, it takes a lot of preparation and much practice below the Death Zone.

Let’s see how this translates to building a business. In the early days, a business relies on a handful of founders and key employees. Their main focus is to find a repeatable and scalable business model, often called the "product-market fit". This tight group is motivated by owning a big share of a yet-to-be-valuable company as well as by having fun in a highly transparent and informal environment. If things go well, the group may eventually agree that a product-market fit is found. What's interesting is that while there might be a good amount of evidence to support this, a major leap of faith is still required to prove that it works "in the wild", as an actual business. And to prove this, the company needs to grow. Enter the Startup Death Zone.

The company increases headcount to achieve scale, to get to the fundamental proof of having a working product-market fit. New employees are different from that initial “special ops” team in that they are less excited about high-stakes games, an informal organizational structure, and unpredictable working hours. These new employees join a company that has graduated from the proverbial garage and is about to become a real business. They are motivated by good salaries and stock options, but, most importantly, they are motivated by having the feeling of riding a rocket ship.

And therein lies the grave danger of the Startup Death Zone. The only way for a company to survive is to grow quickly while in the Startup Death Zone. The only way for a mountaineer to survive is to move quickly and purposefully while in the Death Zone. A seemingly minor slowdown in company growth may trigger a disastrous cycle, when even a little bit of doubt among employees sets off a real slowdown, causing more doubt. A minor mistake of a mountaineer exposes her to the increased possibility of another minor mistake, and when minor mistakes compound, things can quickly spiral out of control and lead to tragedy. Overnight, an awesome startup can turn into a toxic wasteland. And, in a matter of minutes, a seemingly well-run expedition can turn into a struggle for survival.

A successful company comes out of the Death Zone when scale has been proven—it continues to operate as a well-oiled money-making machine independently, or joins forces with another company. A successful expedition comes out of the Death Zone when the mountain has been submitted and the most dangerous part of the descent is behind.

Over time, as mountaineering technology matured, a new approach to passing the Death Zone emerged—supplemental oxygen. With supplemental oxygen, there is a lot less strain on the human body to perform at extreme elevation. With supplemental oxygen, not as much preparation is required for entering the Death Zone and staying there longer is not nearly as dangerous. Less-experienced climbers may attempt summits previously thought unthinkable, while not having to consent to extreme risks or rely on extreme luck.

Enter VC funding. A company that convinces a venture capitalist to make that leap of faith required to get from "we think we found a have a product-market fit" to running a real business, proceeds to raise a series A. With the extra money, the company tries scaling and flaring its model quicker and hotter. The money also allows the company to remain in the Death Zone much longer, and to enter less prepared. It's even possible to go through fundamental changes in business direction while in the Death Zone, and still reach a successful exit. But, just like with oxygen in the mountaineering Death Zone, startup disasters become much larger at scale, more unpredictable, and more sudden. They affect not just the "experts" but also the unsuspecting “tourists”, and often to a higher degree.

Death Zone-related tragic events actually happened in both mountaineering and business. In 1996, eight mountaineers died climbing mount Everest, largely because of what amounted to recklessness allowed by supplemental oxygen. In the dot-com bubble, the Death Zone funding supply extended into public markets, with disastrous effects. Both events were much reflected upon; systemic changes were called for in both industries.

While it is impossible to add supplemental oxygen to an ongoing climbing expedition in any amount that will allow it to achieve “unplanned” success, like going to a higher summit, it is very much possible with venture funding. Otherwise successful companies that execute exceptionally well against their planned climb are seduced to load up on oxygen, gather "tourists", and keep heading deeper into the Death Zone, in search of that elusive higher mountain.

Team Chat: The Trouble with Guest Access

By Andrei Soroker

As team chat is rapidly replacing other forms of internal business communication, it's not surprising that companies—and agencies in particular—are increasingly using this technology for external communication as well.

While this is, overall, a welcome and exciting development, significant dangers lurk beneath the surface. In this post, we'll take a look at a few of these dangers.

Since email continues to serve as the preeminent cross-company collaboration medium, we'll also consider how some important workflows differ between email and team chat.

Teams Don't Scale

With time, accepting a new Slack invitation is becoming a bigger and bigger ask. If 10 of your colleagues need to join as well, the ask gets multiplied by 10.

(It doesn't have to be Slack—any team-centric system with guest or multi-team access will have the same problem.)


Figure 1: Artist's impression of a decade of joining Slack teams

Being in many teams with the same group of people means that you've got as many unique direct message (DM) histories with each person as there are teams. You have to be vigilant to always head to your "home" team to DM with your colleagues. If everyone has the same avatar and name in each team, things can quickly get confusing.

This may not seem all that bad, beyond the obvious observation that being a guest or a full participant in many teams doesn't scale particularly well.

But, we're just scratching the surface. There are serious problems with guest and multi-team access—ranging from project management to data governance.

Presence and DM Considered Harmful

When you give your customer access to your team's online presence, along with ability to message every team member individually, you're summoning Sauron.

It's often noted that the beauty of email communication is in the ability to respond at your own pace. With email, you're offline by default.

If you work at an agency (management consulting, PR, marketing, development, design—you name it) and you've got many companies as customers, you're undoubtedly tending to multiple concurrent fires at any given moment. This often means hopscotching around the schedule and the communication matrix with the goal of maximizing throughput ($$) without blowing deadlines or pissing off clients. It's a delicate dance.

Email and its "offline by default" mode lets you control the switchboard explicitly.


Figure 2: Explicit control of the communication switchboard

Email has many other redeeming qualities, like the ability to forward messages, a global user directory, and being truly cross-platform.

For tight collaboration—with fires aflame and all—email kind of sucks. Hence the recent and ongoing hypergrowth in the team chat space.

Team chat makes it really easy to tell whether someone is online or not—this feature is called presence. Another near-universal feature of team chat is direct, one-on-one messaging (DM).

Turns out, presence is not necessarily desired in agency-client communication, and neither is the ability to DM.

Here's how the problem plays out.

You've got three customers, three projects. Your team are guests in each customer's team chat. You've got major fires with two projects and just a little bit of smoke with the third.

The third customer, the one with the smoke, engages your team in a conversation—you're all online—available!—after all.

You ignore. Not because you don't care, but because your entire career hinges on preventing the two burning projects from turning to ash.

The third customer thinks that maybe you didn't get the messages, so he DMs you. You ignore for a few hours, then respond with "I'm so sorry," and come up with chipper-sounding reason for being slammed.

Now he knows you're ignoring him.

Just to be sure you respond from now on, the third customer stops using the multi-user channel altogether in favor of DMing you. Now you have to copy and paste stuff from your DM with the customer into your "home" chat, so your colleagues know what's going on. So long, transparency!

The same scenario is more likely than not to play out on every single project, causing a bit of a mess.

Presence and 1:1 DM is a privilege for inner-circle colleagues. Extending this privilege to customers and other external contacts is not a great idea.

They Control Access

Whenever two companies are engaged on a project, each party needs the ability to unilaterally invite additional members to relevant project communication channels. Guest access robs the guest party of this ability.

Complex, long-running projects often require the attention of experts to solve critical, but very well-defined problems.

To maximize the effectiveness of an expert, a project manager has to engage the expert—call the Wolf—at just the right time, provide the least—but sufficient—amount of context, enable the expert to temporarily take the wheel, which will often include calling their own Wolves, and remove the expert once the problem is solved.

Traditionally, this has been handled over email, but email is notoriously unkind to experts in the long run. Here's how.

Bob, the project manager, is faced with a problem only Alice can solve. Bob adds Alice to the main project email thread, provides sufficient context, and asks her to steer. Alice solves the problem with the help of Jo, who is also copied, but neither Alice, nor Bob can get Alice or Jo reliably removed from the thread going forward.

Alice solves critical, but well-defined problems on many concurrently-running projects. In the end, Alice, Jo, and all other experts get every single email for every single project they touch.

This is one of the most common criticisms of email—it's hard to modulate noise and almost impossible to undo "invitations".

If you're the one inviting customers as guests, team chat actually solves the problem of the ever-expanding noise for your experts. You're free to bring them in and out of channels as needed, they are free to engage their own experts, and everyone can use notification settings to ignore anything that doesn't concern them.

But if your team are guests in another company's chat, you lose the ability to invite your experts—instead, you have to ask an admin of the other team to do it. Your experts are even worse off—they have to ask you to ask an admin for further invitations.

Relinquishing the right to engage and disengage team members at will is a huge problem for project managers—it hinders the very essence of the job. Project managers absolutely need the ability to unilaterally grant and remove access to a project's communication channels.

They Own Your Data

Whenever two companies are engaged on a project, each party should own a complete copy of all communication history at all times. Guest and multi-team access prevents the guest party from owning history.

The problems caused by allowing DMs and presence in vendor-client communication, and the inefficiencies in project management process introduced by the lack of access control are significant.

Still, they can be dealt with by patience and clerical endurance, so to say. As long as clients pay their bills, agencies will take a near-arbitrary amount of abuse.

The biggest problem—one that simply cannot be ignored by any serious business—has to do with ownership of communication data. If your agency are guests in a customer's team chat, you're always a few hostile clicks away from losing all collaboration history.

The example scenario is simple: your agency spends a few months working on a project. You believe the resulting deliverable is according to spec. The client disagrees. The client refuses to pay, breaks off communication, and revokes your guest access from their team chat.

Time to sue!

You see where this is going: you have no access to the hours of chat transcripts and gigabytes of shared files proving your case. Your client may delete it all and plead ignorance.

The number of ways in which this turns ugly is endless.

No legal counsel would advise or sign off on a collaboration solution where your company does not own the communication record.

But We're Never Guests, They Are

What if you're always inviting clients to your team chat, and not vice versa?

There are two problems with this approach.

One, it can't continue forever: sooner or later you'll encounter a client in the know. Since they pay the piper, you won't have much choice but be a guest in their team chat.

Two, as Confucius once said, what you do not wish upon yourself, extend not to others.

Big Company Mergers and Acquisitions: Dealing with Collaboration Systems

By Andrei Soroker

Some of the most common questions we encounter from prospective customers involve mergers and acquisitions: what happens to established non-email collaboration pathways at two companies once they are required to combine?

"Small big" companies—a couple of hundred people on the acquirer side—don't have much of a problem: the acquiree either gets fully absorbed into the internal real-time collaboration system of the acquirer, or a Sameroom-like service is used to establish bridges between the rooms or channels of corresponding departments at both firms.

The reason why "small big" companies don't have much of a problem with this is because they tend to be young enough to have adopted team-centric collaboration tools, like IRC, HipChat, or Campfire at inception (so, they actually have rooms or channels to bridge, and know how to use them), instead of older one-to-one IM services, like AOL, Yahoo, or Microsoft Communicator.

It's the "big big" companies, at least a couple of decades old and with thousands of employees, that tend to run into issues. At such companies, it's common to see heavy reliance on email and phones for nearly all business communication, with "IM" being nothing more than a lightweight interrupt — "hey, you available?", or "what's he talking about" (during a conference call) sort of stuff.

(With plenty of team chat used by small groups in shadow IT mode, but for the purposes of this discussion, we'll pretend that isn't happening.)

At the "big big" companies, equally important to sending these lightweight messages is the concept of presence—color-coded status showing a user as online, away, busy, or offline.

The reason for this is historical: traditional instant messaging and presence systems—IM&P for short—attempt to mimic in software the idea of a factory-type environment where everyone is co-located within the same physical space and one can glance at a chair and see the "presence" status of its occupant.

The presence indicator approach worked reasonably well because when most of these now-"big big" companies hit success and began scaling, they scaled "vertically": to new floors and adjacent buildings, as oppose to "horizontally": across cities and time zones.

Because of this history, when "big big" company IT staff consider the technical aspects of merging two collaboration systems to establish a merger task force involving subgroups from parallel business units at each company, they often envision something like this:


(We didn't connect all the dots, but the idea is that everyone is connected to everyone else individually.)

This is called federation—a way to merge user "rosters" in IM&P systems of two companies.

It's a functionality that exists out-of-the-box in common "big big" company IM&P systems: Cisco Jabber, Skype for Business Server (not Cloud), IBM Sametime, and a few others.

Quite often, federation suffers from an intention-solution conflict: the M&A stakeholders view federation as a way to foster efficient collaboration between related groups at both companies to ease a traditionally-painful and time-consuming integration process, but instead all they get is the old one-to-one instant messaging and presence.

One-to-one communication contradicts the goal of connecting groups not only in the most obvious way—it's one-to-one as oppose to many-to-many—but also by offering diminishing, or even harmful returns in scenarios where openness and transparency of information is pivotal to successful integration of business processes between two companies, each with unique culture, history, and belief system.

Additionally, a traditional federation solution may disappoint because M&A scenarios usually exhibit a dramatic departure from the factory-centric assumption of traditional IM&P: companies tend to be in different geographies and time zones, rendering the concept of "presence" largely irrelevant.

An alternative approach involves another out-of-the-box feature of most IM&P systems: persistent chat rooms.

Persistent chat rooms are available in most "big big" company collaboration systems, like Skype for Business Server (not Cloud) and Cisco Jabber, but are disabled by default in both.

Enabling the feature involves a similar amount of work as enabling federation, but the results—with a little help from Sameroom—would potentially be more aligned with the original requirements:


Setting this up between Cisco Jabber and Skype for Business Server would require using a Sameroom Proxy for each, with the high-level architecture of the integration looking something like this:


The result can be powerful. For example, it becomes trivial to replicate a source code repository event feed in Jabber and Skype for Business. Here is an example of us doing just this, with a Jabber client running on Mac and a Lync/SFB client running on a Windows 8 VM:


The actual data is coming from a Fleep room with GitLab integration enabled:


Anyone with access to one of these rooms can see what's going on.

In this model, users don't see the membership or presence of users in connected rooms—all focus is on content. It's implied that membership will change over time, that occasionally experts may join on a short-term basis, and that third, or even fourth parties—such as agencies or contractors—may be invited to connect rooms from their collaboration environments.

This idea is revolutionary in a way that three-way calling was revolutionary—as in not very, but kind of.

If you're interested in exploring an M&A collaboration environment that uses persistent chat rooms and Sameroom, we can help—reach out to or call us at (415) 483-7743. We can also walk you through enabling persistent chat rooms in your collaboration system.

For information about Sameroom Enterprise, see

For Sameroom Security Overview, see

Client Communication is Killing Your Agency (And How to Fix This)

by Andrei Soroker

Many are drawn to the idea of running a creative agency: interesting projects; great creative minds; and, of course, ideas people take notice of. Nevertheless, the challenges of agency life can prove a rude awakening, for the new agency operator.

Keeping your agency profitable relies on many variables. You need even cashflow, dependable processes, and a little bit of luck. That said, the lifeblood of any creative company is communication. That’s what I’m going to cover today: how client communication impacts the bottom line—and the quality of life for all involved. (Oh, yeah, and I’m pitching my product, too—because someday it’ll save your ass.)

Slo-mo to Crunch Mode

As you probably already know, the underlying challenge for any agency lies in establishing a healthy balance. This requires you to juggle a number of ongoing projects and delivery times, while maintaining work quality. You’ll need to do this while managing a sustainable pace that’s compatible with the talented mortals you hire.

Before I get into that, though, let’s step back a little and look at how you got here.

You start off as an energetic trio with a few small clients. After struggling for a while, you land your first substantial client. You’re stoked. This is your big break. Pull this one off, and you know there’ll be (lots) more.

The project completes ahead of schedule, and with better-than-expected results. Sally, your client contact, is thrilled. She immediately commissions another project. She also tweets excitedly about finally discovering a rare BFF in the “evil agency world.”

You enthusiastically dive into the new project. With a little money in the bank, you hire an employee. Meanwhile a brand manager at another organization spots Sally’s tweet—and wants you to help with his project. His previous agency botched the project and he just needs this problem to go away. Oh right, and the RFP you submitted 6 months ago finally comes through.

Now, with three top-priority projects, you find yourselves in crunch mode. As a result, everyone in your little shop is stressed out. It’s not so much the work—you know you can pull that off. The problem comes down to all the emails and meetings. If you didn’t have to deal with all of those, you could actually get some real work done.

All the Goddamn Emails and Meetings

Emails and meetings (virtual and in-person) are high touch, time-expensive means of collaboration. Since they are so all-consuming, a team in crunch mode will do everything possible to avoid them. This, is a dangerous habit, though. Skipping communication widens the gap between check-ins, increases the risk of course deviation, and tends to erode trust.

Weak communication takes its toll on a team. The more time-consuming and fractured it becomes, the more you’ll see staff drained. Nothing quite sucks the life out of a “young, small, bespoke, and energetic team,” like strained communication. A predictable side effect of this stress is weaker creative product, diminished morale, and lower overall productivity.

The funny part? Just a few years ago agencies dealt with almost the exact same problem with their internal communication. Team chat (Campfire, Slack, HipChat, etc.) changed all of that. Over just a few years, this medium has become the de facto method of office messaging. As a result, some agencies wiped-out internal email almost entirely.

Curiously, the problem remains for external communication.

What About Guest Access?

Of course, there are workarounds (most commonly, some form of guest access). With this approach, you invite a client into your team chat account. This almost always improves agency-client collaboration—but it has issues.

For example, clients commonly invite the agency into his/her team’s chat—which forces you to use another chat client/account. You can protest this, but (for the most part) resistance is futile. He who pays the piper calls the tune. If this scenario repeats with even a few clients, the situation quickly becomes unwieldy. As a result, you’re left juggling numerous applications, tabs, and teams.

Another common problem is in not having all the right people in the chat. This happens as a result of a lost/forgotten invitations, guest access feature limitations, or team members refusing to use a particular chat system. Ideally, each party (there could be more than two) would have full jurisdiction over who has access to project communication on their side of the discussion.

The biggest issue with guest access is the change in semantics for data ownership. With email, both parties can run basic forensics on previous correspondence, since everyone gets a copy. This doesn’t happen with team chat, though—because in this setting, the team owner owns all the data.

We Saved the Day

(This is the part where I pitch the thing we made.) offers a surprisingly simple solution: it connects a chatroom in your team chat to a chatroom in the client’s team chat. If a third party is involved, you can connect to a chatroom in their team chat as well. Want to get crazy? You can add a fourth party, fifth party, et cetera. Once connected, all chatrooms get their own copy of each message.

A major benefit of this approach is that no one’s forced to use a chat tool they can’t, or don’t want, to use. Let me put it this way: Sameroom is like an invisible layer of plumbing that replicates messages between connected channels or rooms. Simple, right? (You might be surprised by how confusing the idea is to some.)

With Sameroom, admins from each team are free to establish their own policy as they see fit. Plus, Sameroom relays messages to every connected chatroom on a project. As a result “carbon copies”—owned by their respective sides—are readily available. This is a must-have, should you (God forbid) find yourself in the midst of a lawsuit.

Most new agency owners think creativity will be an issue. They fret ideas, concepts, and awards. Most times, though, this isn’t what takes down an agency. You probably have more good ideas than you’ll ever use. However, if you can’t communicate efficiently with your clients, you’re already sunk.


Still have questions about how your agency can use chat to communicate with clients? Drop me a line or call me and I’ll help you work through any problems.

Thanks to Eric Karjaluoto, Peter Hizalev, and Boris Soroker for reading drafts of this.