Last but not least, and I'm not sucking up because it's your blog, we like Meldium a LOT. When I joined the company all the passwords for apps we shared were stored inside of a Backpack file. Yeah.
I had to hold a gasp when someone first gave me access to them. I originally migrated all of us to Passpack. While they provided the security and granularity I was looking for, I was forced to create a screencast to explain to a team of professional software developers how to start using it. The user experience was just not there.
When it comes to security, user experience is the most important thing to nail down because if users find your security tedious — no matter how important that security is — they'll find a way to circumvent it. And they did. Our marketing team was using LastPass (which has very similar issues in my opinion) and after tinkering with the foolish idea of building my own solution (maintaining security-sensitive software is a full-time job) I briefly considered using GitHub's stillborn Swordfish app but the team features were non-existent.
That's when Meldium appeared. You solved many of the core issues I needed addressed. The design decision of not letting people you share credentials with actually see the passwords at all is brilliant. Beyond the simple security advantage, it enforces centralization. No one on the team can copy a password somewhere else, unless we specifically let them. That means no one will ever have an outdated password when (not if) we need to rotate passwords. It also means that I don't have to worry about someone leaving the team with a stash of passwords I then have to update on all the services we use. So many hours of worry and tedium we get back.
The actual implementation continually blows my mind. You're basically using a man-in-the-middle attack for good, if I don't betray my poor understanding of the concept. A less malignant analogy would be to liken it to the way telephone companies operated switchboards before individual telephone numbers connected people directly. You had to call the central and ask the operator (i.e. Meldium) to talk to your friend Frank McFakeperson in Ipsum, South Dakota (i.e. MailChimp) and the operator would patch you through to them seamlessly. Feel free to use that to make a kick-ass retro ad one day.
How does your team choose & adopt new applications?
Being software developers ourselves, and picky ones at that, we obviously pay close attention to design. By that I don't just mean aesthetics. Although a team that knows how to present its product inspires much more confidence than one that doesn't. That's especially true for business-criticial software that we're likely to invest a lot of money in.
By design, I also mean:
- How thoughtful is the tool?
- How careful are the considerations?
- How well does the tool solve the problem at hand?
- Am I jealous that I didn't build this myself?
Pricing is of course important. We ditched CoTweet when they switched to a ridiculous pricing model after a redesign where they asked us for thousands of dollars right off the bat. There's nothing more offensive to developers than a company that tries to force them to talk to a sales person on the phone. It's easy to understand, really. If you're a shoemaker who builds dress shoes and you go out to buy pricey boots, you expect to skip the pleasantries and the kind of sales pitch they use on regular customers.
And yet somehow, all around you see these business-to-business or "enterprise" services who expect you to get in touch with a sales person so they can hold your hand, give you a "personal demo" of the product, as if the product can't stand on its own merits. It's not just condescending, it also indicates lack of confidence in the product. I usually drive right past these services to find someone who tells me what problem their product solves, how they solve it in a way that is relevant to us, and how much money they want for it.
If they offer a free trial for me to play around with the product, it can be a great idea. That is, if they have spent the time to create a good "blank slate" experience, which useronboard.com provides tons of amazing examples of. If your tool requires a lot of data to become useful, then show me example data that allows me to see it working the way it eventually will. Many good services out there don't do that, which means they waste the advantage of their free trials, and I find my inbox full of cool products I've never really had a chance to evaluate because I don't have time to either hook them up to our apps or create test apps.
Mobile applications that allow you to see what the full-fledged web service offers while "on the go" are nice when tightly-bound to our core business (analytics, error reporting, business metrics). I wouldn't say it's an absolute deal-breaker otherwise: GitHub for instance is quite crippled on mobile and that's not too much of a problem.
We don't hire often enough to justify building bootstrapping scripts for our development environment, especially since it's not that hard to set up. Tools like Dropbox, Meldium, and GitHub make it very easy to get people ready for work on day 1. The only hurdles we have left to face are more specific to our production stack, which goes to show how much easier things have become.
On the information side of things, I built a tool called Orientation. It allows us to disseminate internal information by writing short articles on the simplest topics. It allows new people to do fuzzy searches in a similar way to Alfred and Spotlight. I plan to open-source it soon because I think centralized knowledge is one of the biggest bottlenecks of modern companies. It's far too common for people to explain the same thing over and over again to different people. We don't tolerate it for customer support (we end up building FAQs), I don't understand why we do for co-worker support. Orientation also allows anybody in the team to look up anybody else by face, by what they work on (not their title) or their name and email. It's nice when people are too shy to ask someone what they do or if they forget someone's name which starts to happen when you grow beyond 20 people.
Remote work isn't something we're doing right yet, but we're working on it. Just a year ago we only had one person on the team who was remote full-time, now I'm the second one (and I'm six hours ahead in Paris, France) and we have several other part-time remote people who don't live in Orlando and drive to the office only a few times a week. Many of us are remote part-time, on Tuesdays and Thursdays, so we can focus better by avoiding context-switching and commutes, taking care of our young children and/or pets, etc.
The problem is that since most people aren't completely disconnected from the office, we still struggle to be considerate to people who can't meet at the office to catch up on recent progress. I recently set up what I like to call our "Envy Deck," which is simply an iMac with a much better webcam than the default iSight and a highly sensitive omnidirectional microphone. Using a cool service called Appear.in it allows us to keep an open audio/video link between every remoter and the office. Appear.in uses the experimental WebRTC API which basically means everybody is connected peer-to-peer. The big draw over something like Dropcam is that it's a much better multi-way system. You can always see people's faces and they can speak back, so in way it allows them to be "present" at the office. We had it always on at first, but it's a little distracting and a bit creepy when you forget about, so now we just activate that spacetime portal whenever we feel like it.
Persistent public chatrooms with either Campfire, HipChat, Slack or IRC are a big deal too. It's very important for people who are remote to feel like they're in the loop, which means that if a conversation can happen on a discussion room instead of a physical meeting room, it should. We try to have as many chat rooms as we have projects in order to increase the signal-to-noise ratio.
Another great tool is ScreenHero. It has allowed me to remote pair program with Tyler, an Envy developer in Tennessee, on open source projects like rubygems.org; to have one-on-one conversations with John who needed to understand our product better when he joined our sales team; to have debugging sessions with new team members or front-end developers instead of wasting time chatting back and forth with very little context. ScreenHero makes it incredibly easy, even if someone uses tmux with Vim and the other Sublime Text or Atom. It's even great to use ScreenHero to avoid making someone in the office switch contexts when you need a sanity check, since it's always better to look at code than try to describe a weird problem you're having.
What would be your dream setup? What would you wish were easier or better?
I hope browser vendors dramatically improve the performance of WebRTC so it's not so CPU-intensive as it is today. It has gotten much better in recent builds of Chrome though. I would love for us to have multiple "decks" in the office where you can hop on to talk to someone who's remote or even pair with them that way.
I wish it were easier to ensure everybody on our team uses proper security. Meldium is a good first step but too few business service providers offer proper encryption for communications or two-factor authentication.
I've recently started using Librato to create the same kind of "information radiators" (large LED screens with actionable business metrics displayed on them) that I've heard the Square team uses throughout their office. It's already helped us identify abnormal activity for Code School and investigate it. I think aggregating and surfacing data about our business in a highly digestible way to encourage problem solving.
I truly wish secure communications for individuals and teams were easier. Keybase.io and GPGTools are interesting improvements that inject much-needed design thinking into the security and cryptography worlds. This frustrates me so much I recently gave a talk about it called Rational Security which does feature a bunch more tools like this.