Syncpocalypse is upon us. It’s time to get our ducks in a row.
For your listening pleasure, here’s Jeff Beck’s Because We’ve Ended As Lovers
(That’s me playing bass with Revival, but it was a rehearsal so don’t sweat the details, Um’K?)
Google’s Tweet:
We’re retiring Reader on July 1. We know many of you will be sad to see it go. Thanks for 8 great years! goo.gl/7joct
There are about 2,250 retweets at the time I’m writing this. Here’s the full thread on Twitter. There are many … um, not-so-nice comments there. (Of course what did we expect, right?)
Over the years, I’ve come to the conclusion that one of the most important class of bugs any team must fix is what I call “Trust Bugs”.
There are lots of sub-classes of trust bug, each with their own telltale manifestations, but assuming good intentions, trust bugs almost always have their root cause in mismanagement of a team or project. (Is there any difference?)
What is a Trust Bug?
It’s pretty simple really:
A trust bug is any project failure resulting from people or teams not trusting each other.
Ok, that seems stupidly obvious. But when you’re in the team, or you are the person it’s sometimes not so easy to see what’s going on.
An Example Trust Bug
A team of developers is tasked with building a set of custom UI controls that pull data from an online database. The database team has dutifully provided API documentation, and even an SDK for the current version, and is in regular communication with the UI developers.
The database team, in the meantime, is working on changing their underlying schema to version 2.0, and are under deadline pressure to complete this work. In the process, they’ll be updating their existing SDK, and deprecating their current API…
But because the project is secret, they haven’t said anything to the UI developers — even though they work at the same company on the same product.
Blam! Trust Bug!
The database team has information about their roadmap that is absolutely critical to the success of the UI team. But because the database update is both taking all their time, and is secret for so-called “business reasons”, they don’t share with the UI team.
So what happens next?
The UI team becomes increasingly agitated that they can’t even get answers to seemingly simple questions of the database team. They start to badmouth the database team at lunch, at social events, and to their managers.
In the meantime, the database team is becoming increasingly frustrated with the UI developers for bothering them all the time, while they’re heads down on a project with such critical business impact.
After all, if it weren’t critical, then why the heck would it be so secret?
So the database team completely cuts off the UI team, at least until the schema update project is done.
The UI team, which has a dependency on the database, assumes they can ship on schedule but then the rug is pulled out from under them, and they have to either scale back their plans, or push their release schedule back. Either way their product suffers, and everyone comes out looking incompetent.
It Only Gets Worse
So what does this mean for future projects?
At this point, the UI folks think the DB folks are idiots for living in their own world of schemas and database upgrades, and that they pretty much suck at project management and partner relationships, since they haven’t even updated their API documentation, much less their SDK. And when the SDK update does surface, it turns out it’s not backward-compatible and the UI team has to spend weeks updating their own code to even get running again.
And the DB people think the UI people are too demanding, and can’t respect their schedule. They just don’t understand how sensitive this project is, and how trivial the SDK and documentation are, compared to the real work of updating 6-petagazllion records on a live service, without taking down the entire company.
Worst of all, the managers of both teams feel the same way. They don’t trust each other, and the distrust is bolstered by bitch sessions over team lunches and happy-hour beers.
So the mangers and project managers start looking for a way out.
They build expensive process controls, centered around forcing each team to keep very strict commitments to the other. They institute communication protocols that require that everyone attend or present at multiple meetings each week. They want reports with spreadsheets and graphs that they can use to force the other team to meet their schedule, and not change plans in the middle of a project.
End result: Organizational Paralysis
It’s all about open communication!
The story above is probably an extreme example. But at many big companies, that’s exactly what happens, at least some of the time.
So how do you fix this? Open communication:
Make trust a priority
Let your people talk to each other! Don’t silo their communication about project to a “need-to-know” group unless you absolutely must.
Get teams to invest in each others’ success.
Don’t set up incentive systems that inherently make teams compete against each other. If you do, then you’ll end up with one winning team, and nine failing teams.
Find ways to reward cross-team collaboration, without forcing it.
If people are invested in their partnership’s success and not just their own team, then they’ll work super-hard to make the partnership successful.
And when people are allowed to share information freely, collaboration will be much easier.
When we don’t have enough information, people naturally become defensive (or even paranoid), and move to protect themselves and their own team or fiefdom rather than invest in products, customers or the company itself.
More soon…
I’ll write more in a future blog post about how to recognize Trust Bugs, and some specific things you might do to fix them.
In 1980, my uncle gave me an Apple ][ plus for my birthday. I had been telling any adult who would listen for about a year that I wanted a computer. Most of the time the response was something along the lines of, “Why do you need a computer?” Honestly I didn’t know, but I knew they were cool, and I fantasized daily about owning a Commodore Vic-20 or a Sinclair ZX80. Honestly I thought the Apple ][ was pretty far out of reach for this 11-year-old, but my wealthy uncle thought different.
It didn’t come with a disk drive – he didn’t know any better. It had 16K of RAM, and when I got it, I didn’t have a monitor or even an RF-modulator to hook it to a TV. I could literally do nothing with it on the day I got it. Fortunately my mom had an old B/W monochrome monitor kicking around her lab, and she brought it home so I could use the computer.
It was about 6 months before I got a disk drive, and during that time I wrote many short programs in AppleSoft BASIC, occasionally saving them to audio-cassette, but more often losing my code when the computer was turned off. The one (there was only one) at my middle school had a disk drive, and I owned a single 140KB Verbatim disk at first. I kept all my work on that disk, which still exists in a box in my mom’s basement in Kansas City as far as I know.
The Apple ][ plus was an all upper-case computer with a 40×25 character display. There was a shift key on the keyboard, but that was for punctuation and special characters over the numbers. There was a CTRL key, an ESC key, left and right arrows, and a RESET key. But there were no function keys, no Alt, Option, Fn, Tab, Apple or “cloverleaf” keys, and no numeric keypad. (I have a slightly interesting story about the REPT key for another day.)
Input was super minimal:
Little did I know at the time, that the first spreadsheet program had been developed a year or two earlier. Enter Dan Bricklin’s and Bob Frankston’s VisiCalc. Here’s a screenshot:
I didn’t get my hands on VisiCalc until 1981. The first thing any Apple ][ VisiCalc user had to know was that the ‘/’ (forward-slash) key brings up the menu on the top row of the screen. You used the left and right arrow keys to pick a top-level command, and hit RETURN. At least some of the commands then had a sub-menu which would appear on the second row, and then you’d hit RETURN again to execute the command.
It was a really elegant system for using just four keys to represent a command hierarchy on two lines of all upper-case text, just 40 characters long. That was about 8% of the total available screen real estate, which was otherwise occupied by some status readouts – location, cell contents, formula, etc. Bob Frankston wrote up his experience of Implementing VisiCalc, including a few paragraphs about how the ‘/’ key worked.
In late 1996, 15 years after I first saw VisiCalc, I started my own “online journal” and completely subconsciously copied this idea for my site’s navigation. (I only just now realized that.)
I have no idea if this was an original idea introduced by VisiCalc, but whoever’s idea it was, it stuck. We have today menu hierarchies hanging off the top of screens on the Mac, and at the tops of windows on Windows, at least until Metro broke the paradigm — we’ll see how that goes.
You’re rambling, Jake – what’s your point?
Something else that stuck around, at least in the spreadsheet world is the ‘/’ key. I don’t know if they copied it directly from VisiCalc or if Lotus copied it first. And I’ve never used Lotus, so I don’t know if they used it or not.
But to this very day in Office 2010 on Windows the ‘/’ key puts focus on the “Ribbon” – the 2010 version of those top two 40-character, all upper-case, B/W inverted rows of text on the Apple ][ version of VisiCalc.
Try it for yourself – it’s pretty amazing.
Sadly, the Mac version of Excel doesn’t do anything special with the ‘/’ key. Somewhere along the line, VisiCalc’s religion was lost to the Apple universe, but it still survives over in Microsoft-land.
Leave a Comment