Chapter 3 – Transactional vs Social Interactions

This topic is a bit challenging, but not for any bad reason whatsoever.  I assume the majority of the folks reading this are techie introverts on the Myers Briggs intro-extroversion scale.  I, myself, score so far into the introversion side of the scale, I’m basically off the charts.  With that, sometimes, comes a hesitance to socialize.  Not out of shyness, which is the common misconception.  But purely out of discomfort.

You’re going to want to work on that discomfort level a bit and I’ll explain more in the section below.  What I’m going to describe are the different ways in which you can interact with your co-workers.  And it’ll hopefully be clear why working on that discomfort will be helpful professionally.

Transactional: Turning Requirements Into Results

“What are your requirements for this project?”  This might be a common thing to ask an internal customer.  And, let’s be clear: your role as an architect is to intake a series of requirements, understand the guardrails in place, and produce results for those customers.  For the company’s bottom line: you need to do stuff.  So, you do need to be good at that in an architecture role.  It’s perfectly acceptable for an architect to gather up the aforementioned requirements, run off to his or her office, cubicle, or hole in the wall, and produce an output in the form of a design.  Be it for networks, systems, security, or whatever.

Doing this quickly and efficiently will make the customer happy.  There’s no extra time spent socializing about things that may or may not be superfluous to the project.  It’s get in, get the list of requirements, get out, and back with a solution.  Done.  Over and over again.

But is there more?  As it turns out, there’s a lot more.

Social: A Path To Open Collaboration

The social approach to working with coworkers is a bit more difficult, because it’s somewhat personality-dependent.  What works for me might not work for you, and likewise what works for you might not work for someone else.  It’s really up to the architect, whether new or experienced, to figure out how to work on this.  And as I stated above, for us hyper-introverts, that can be a bit of a further challenge.  But what do I mean by social?  Isn’t it important to produce output based on requirements?  It is.  And this isn’t an either/or sort of thing because you do still need to produce output.

A social architect is one that opens him or herself up to understanding more than just the customer’s requirements.  What about some of the seemingly unrelated challenges the customer might be facing?  What about some of the external pressures they’re facing?  Showing genuine interest in these aspects of their roles opens you up to being more collaborative.  In fact, given the choice between a purely transactional (and successful!) relationship and a social one, the customers will likely appreciate the former, but remember the latter.

Are there immediate advantages for the company?  Nope.  In fact, it may initially seem like you’re wasting your time because nothing tangible is being produced from those efforts.  But recall the last chapter on strategy: that’s exactly what this is.  It’s an investment in the future: the customers will be more likely to want to continue working with you on new projects.  And they’ll be open to input on those projects from you.  This is huge because it gives you the opportunity to influence their projects; you’ll have the chance to nudge things in directions that will be beneficial for both groups.

How do you do it?  Again: it’s going to be different per person, per group, and per company and environment.  I can’t write out a checklist of things for you to do to get there.  All I can do is provide an example of how I did it in the following section.

How I Did It

To be completely honest with you, I’m still working on this.  But I got started on that journey, again, during my time at AOL.  There was always a hate/hate relationship between the networking and systems folks at AOL.  That, by the way, isn’t unheard of.  In fact, it’s been fairly common in all of my subsequent jobs.  And it’s usually a communication issue, not a technical one.  About half-way through my career there, I came to the, “duhhhh…” realization that this relationship wasn’t helpful for either sets of teams, nor AOL as a whole.  To try and remedy that, I asked the heads of each of the respective departments if I could attend their weekly staff meetings, and started doing so.

My intentions were to just be the proverbial, “fly on the wall”.  I’d be there to listen to, see, and understand the challenges from their respective.  Over time, and with specific groups, it turned social in nature.  I’d be invited to their team outings, like lunches.  One team even invited me to their IRC channel, where both work and social conversations took place.  Basically: I became an unofficial member of the respective teams.

Prior to me doing all of that, my interactions with each of the aforementioned teams were very transactional in nature.  I’d get email from them with a bunch of requirements, and I’d do whatever it was they needed done.  Effective?  Yes.  But afterward, the emails turned into conversations, and those turned into back-and-forth collaborations.  Ones in which I could gently apply a bit of influence to designs and ideas.  I’ve carried that approach forward into each of my subsequent roles.

Next: Curiosity and Learning

So how do you want to handle your architecture role?  Hopefully it makes sense that being social with your customers and coworkers while working on various projects leads to greater collaboration.  Next up: Curiosity and Learning.  It’s key that an architect keeps his or her technical curiosity even though they’re not regularly performing technical tasks.