Thursday, December 27, 2012

Techniqued v. defined

About a decade ago, a colleague of mine used this word to describe an odd interaction we'd just had with someone else. It has stuck with me ever since, and I've been compelled to share it a few times over the past couple of months. As with many blog posts, my motive for this one is to document the concept for future reference.

techniqued | tek'nēkt |

verb (techniqued | tek'nēkt |, techniqing | tek'nēkiNG |)

  • the process of leveraging a technique to communicate an idea, point, or concept: he was techniqued into that conclusion. she is techniqing him in an attempt to achieve the outcome she wants. 
We've all likely techniqued someone else, and we've all certainly been techniqued; neither is good. You'll notice it's nearly synonymous with "manipulated." When you're on the receiving end of this, your skin starts to crawl; it's an icky feeling. Sometimes it's not clear when it's happening (when it's done perfectly, you're none the wiser. nothing to see here.), however, if it looks like a duck, quacks like a duck... it's a duck.

If you're consciously techniqing others, you're leaving a bad taste in the mouths of those around you. Reconsider your approach as you'll get a lot further, and deeper, in life.

Life and work are too short and variable to apply heavy prescriptions to the act of communication anymore. Everyone has so many tools and so much knowledge at their fingertips, that techniqing is just too inefficient an approach to be useful at today's pace.

If you're, consciously, or unconsciously, techniqing on a regular basis, try having a more real-time, bi-directional interaction with those around you. Whatever technique you're trying to apply can't keep up in today's knowledge rich environment. Embrace the humanness of the engagement. Life is not an HBR article. There are nuggets of communication/management information in those management journals, but they're not bibles; don't treat them that way.

If you're being techniqued, you don't have to be. While it might not seem this way, you're actually the one in control. Take it. Illustrate the perspective and variables to the other party that are pertinent to the situation, and drive the conversation the direction you think it should go; ask questions. You don't have to "technique" the other party at all, simply have an open discussion, get what you need out on the table, and let the other party do the same.

There are obviously effective communication "styles" and "approaches," and separating them from the notion of "techniqing" isn't easy. Approaching a conversation "gently" or "carefully" can obviously be highly appropriate and effective. Not everyone's interface is the same: some people respond to direct/harsh interaction, while others need a softer touch. Surprise surprise, the trick is in the balance of it all. Applying heartless, methodical, gate/switch-driven, technique to a human interaction is energy intensive, and ultimately ineffective. Pure touchy/feely exchanges without substance aren't useful either. The point is that one size does not fit all when it comes to communication and engagement. Make sure you have a good balance of gut, heart, and mind when you're communicating with others. Don't be "that guy" who's living their life out of a management consulting manual.

There's a difference between applying a philosophical higher-level approach (e.g. socratic method) to communication, and leaning on tactical/discrete frameworks born out of business schools. One has the potential of bringing out the best in everyone, while the other does not.

I'm finally getting around to attending a Wisdom 2.0 event this coming year. I'm hoping it's a refreshing and progressive view into a lot of this stuff. If you're going too, drop me a line.

Tuesday, December 18, 2012

Speak the Unspoken

Gnip (social media company) grew a lot in 2012. We did a lot a of things really well (we have an experienced, proven, management team), but I personally botched a least one thing.

I let certain aspects of process and reasons for doing certain things go unspoken, after initial conveyance, for too long. Some of this was conscious and intentional ("spread your wings and fly" kinda stuff), but some of it was not. Regardless, some key stuff drifted for too long, and when you have a room full of bright, passionate, driven people, they will find their own way no matter what's going on around them. That's, nine times out of ten, exactly what you want, but unconscious drifting from a tenant is not.

Beating others over the head with process or beliefs is obviously detrimental, but regardless of how much trust and confidence you have a team your scaling and building, it is still a set of people in a room that haven't worked in the new environment together before. Regularly checking in and sync'ing on the key stuff is imperative. Without doing so, key experiences and learnings might not be leveraged well during future challenges; right when they matter the most.

Monday, December 3, 2012

Product or Services? What Kind of Company are You?

At Gnip (a social media company; where I work) we are, of course, always working to "do the right thing," when it comes to how we build software.

There is a lot of great work and discussion going on these days regarding the assurance that the software you write is significantly influenced by your customers (target, or existing). I love the energy around this topic, but as with any trend, it can be taken too far.

What Defines The Software You Build?

If you are exclusively building what your customers are asking for, then you are acting like a consulting firm or a services company; don't fool yourself into thinking that you're a product company.

If you are exclusively building what you think your customers want (without much, if any, empathy for their wants and needs), then you are squarely a product company. You may or not have any customers, but you're indeed a product company.

The art at Gnip is in striking the balance between these two things. We certainly have customers with explicit demands around exactly what kind of functionality they want. However, we don't always build software to match those specific demands. Often we do, but often we do not. We regularly prioritize other features & functionality above what they're specifically asking for. We might do this for a few reasons: one, we know internally that there is simply more important stuff to do (e.g. operational stuff that without, the products we provide will cease to function at all). This is often referred to as "keeping the wheels on." Two, it's an idea that simply isn't in Gnip's sweet spot. Three, which is effectively a summary of the prior two, our vision for our product offering is simply different than what may be suggested by a customer or prospect.

Guess what; that's ok. Our customers love the fact that we have vision and direction around where our products need to go. In fact, that's often a significant reason as to why they pay for our products. They know that their own ideas don't necessarily encompass the broader ecosystem perspective. They know that if we catered to their every whim, they wouldn't be getting any deeper evolution of the offering. They know that we're not an outsourced software development team that they have exclusive control over. They know we have our own creativity and unique perspective to apply to the challenges at hand.

What Are You?

If you're making money on product that is purely a function of your creativity and vision, you are clearly a product company. If you're making money on product that is purely a function of what your customers are asking for, you are a services company. The former is very hard when it comes to software, and is likely going away entirely as a model. The latter is something you can stumble into without even knowing it, all the while thinking you're a product company; then you wake up one day and you're not.

A hybrid is what we strive for at Gnip. I think of Gnip as a product company, yet we invest an amazing amount of time and energy into ensuring we understand our customers specific needs, and build solutions for them. We take those learnings, meld them with our product vision, and out comes software that moves the ecosystem toward a bigger picture, while meeting the immediate needs of our customers.

Combine the empathy for your customer's needs, with where you know the product needs to go, and great product will result.

recent Tweet by @sether motivated this post.