It’s said that only 2 industries call people who use their products “users”: the tech industry, and drug dealers. We here at iAcquire strive to rise above that stereotype: challenging ourselves to break the mainstream and creating an environment conducive to explosive, but controlled growth. Central to that strategy is the culture we’ve developed naturally.
Though for the most part much of our development work has revolved around our internal application called the iRank Platform, the lessons we’ve learned could still be applied, in part, to your situation.
Listen, listen here.
Here’s news for every programmer out there: you do not know any better than your average user. What we find time and again is the simple fact that those who use the product day in and day out are often at a better vantage point to discover when something is wrong or identify what needs improvement.
Our job as developers is not to ignore requests and prance around acting like we know what’s best; it’s to take note of it, put it in a backlog and tackle it based on importance. Keep going with blissful ignorance and you’ll find yourself playing as a parakeet’s parlay. Yes you’re an important player(with a commanding voice, if I may add) but the people who use it are the boss of you. Remember you’re building stuff for them, not because a book or some blog told you so. Ignoring your users might buy you time, but their issues will not go away — it’ll just continue on doubling up.
“Should I babysit my users then?” No. Absolutely not.
“But they’ll keep doing the wrong stuff!” No, no they won’t.
We, as an industry, need to trust people more. We need not assume they’re going to crash the servers — granted that sometimes it does indeed happen but it’s 2012 for Pete’s sake, why do we still act like it’s 1992 and that only WE know how things work?
There’s a commune in communication.
A conversation is not a one way street. But our communication often goes one-way, that is: we tell them what to do, end of story. That often is the fastest way to be out of touch. Ask for feedback. Observe what’s going on. Listen. Once you’ve got what you need, then provide feedback. Explain how it works, why it works that way. Go back to the first step – ask for feedback and so on. No, this is not for the bosses, this is for the team: the same people who live, eat and breathe what it is you’re crafting.
What we find most effective too is writing up post mortems directed to the users affected – especially internal users. If you hire a plumber to fix a leak, how would you feel if he just tells you: DONE! You will ask what was wrong and you will ask how it was fixed. You need closure. In the same way, your users also need closure. It’s not just an emotional yearning; it’s just inherent in how we think. If we do not know why it was leaking, and how it was patched, would we be confident in using the faucet? Or are we going to constantly be second guessing ourselves, slightly wincing every time we turn on the tap?
We’re also Gymnasts
Being in constant communication allows for instant feedback – and that is both a boon and a curse. It’s a boon because we know right away what’s wrong or what’s right. It’s a curse because we know right away what’s going wrong and what should be going right.
More importantly, we know right away when something breaks; and at times, we have to batten down the hatches for protection against an avalanche of bug reports. Say when one of our data sources suddenly decide to change formats, we must have the flexibility and the bandwidth to roll out a patch and keep things humming smoothly, especially when particularly gnarly situations bubble up, such as:
When keys collide
It was a regular wintry Wednesday when a team member noticed something peculiar. A page he was evaluating was returning wildly different results when checked by our platform versus his very visual inspection. He brought it up, it was escalated, and we watched him replicate it. This was just one page out of millions of pages we were examining – we were more than willing to chalk it up as a fluke. But we’re iAcquire. We did our due diligence and ran a system check against that case.
We verified that it was indeed failing for that particular case. Great! Why? Still, we’re talking about one case out of a million. It’s so easy to turn around and look the other way but we didn’t. It wasn’t going to let us sleep that night. We just had to know why.
Ultimately, we finally tracked it to our key generation mechanism. As it turns out, it wasn’t generating enough unique request keys for the scale of our operations. Once identified, the fix was on its way. All within a couple of hours, we were able to turnaround and put up a solution with minimal impact to the user experience.
But our work wasn’t done yet, we still had to explain what happened to the team, and only then were we back to our regular Wednesday programming.
Understanding is so underrated.
At a time when massive corporations, wielding enormous power over sovereign nations, don’t even understand just what exactly it is they’re selling, we take a different approach. Each and every one of us understands the business, ensuring everyone is current and kept abreast of what’s going on. And again, at a time when everyone is just expected to hit the ground running, we actually expend a substantial amount of time in training our new partners – mostly on making sure they realize the value of the duties they’ll be tasked with.
So when a squirrel crawled into a transformer, short circuiting the electric grid of the block we were on, there was no panic. A few groans here and there but overall it was orderly, there was no screaming “the zombie apocalypse is upon us”, paper planes didn’t magically start taking to the air, nor was there any mass exodus towards the front door.
Every one held their place as the servers started chirping audibly about their dwindling battery supply. Within a few minutes, everyone was coalescing into their groups and talking strategies and catching up. As the server wailed and warned of imminent death, we decided to boot it down and continue having our people move up meetings when applicable. Some who were mobile kept powering through and took care of offline tasks. But of course after an hour of no A/C and the full glory of the Arizona heat, inasmuch as we wanted to stay and keep productive, we headed down to the local bar and toasted a few drinks to the squirrel that unexpectedly helped improve camaraderie – and testing the mettle of our culture.
Understanding – that is the key. It is imperative in our culture that everyone understands their task, because it’s integral to one of the first points made: trust. Trust that everyone in the team will do the right thing. If something or someone fails, watch out for it. Listen, because there will most definitely be a loud clang. Communicate what happened and what needs to be done. Be flexible and be willing to roll with the flow. Ensure everyone pertinent to the discussion is involved. Mistakes happen, it’s not the end of the world. What’s important is how resilient the team is in handling roadblocks – and though tech people tend to have a bit of Messianic complex baked in, we need to realize that we’re but part of the team and we really do need to work with other people.
We are a technology company at heart.
That’s why much of this post is dedicated to the company and the process because as a whole, we’re all techies. To discuss the culture of a tech company without bringing up the culture of “the company sans everyone but the tech team” is impossible. We all understand that fact. For this reason, we are non-standard. After all, we’re a company that’s used to eschewing standards – we use Zimbra for our email platform, not Google or Microsoft; we’ve deployed a fat client linux distribution to run from a centralized server to our individual workstations, not Microsoft Windows or Apple iMacs at each and every desk(though they do look nicer).
For this reason, we don’t delineate between techs and non-techs. Everyone is a part of it because iAcquire understands that technology is a tool for the business – the business is not a slave to the technology. Sure it might be hard to work if a piece of tech is down, like electricity for example, but we’ll still keep cranking. The best way to embody that is to invest in the people, trusting in their judgment, and creating an open and thriving environment. At the end of the day, we pride ourselves on the fact that everyone is empowered – not because we were told “you are empowered” but because we all know where we’re at, and where we’re supposed to be.