When in doubt, tell the truth.
A flexible approach to Technical Direction
This is a strange, sort of ex-post transcript of a one-hour talk I gave on October 16th at the 2014 Seattle Interactive Conference. I was speaking to an audience comprised of mostly designers and creative entrepreneurs, though I had telegraphed the talk with the following blurb, and as such, attracted a few other Technical Directors.
A developer-turned-administrator discusses several — completely subjective — tools for weeding out the difference between common-practice and best-practice with regards to development, tech direction, and team management.
The truth is that when I wrote that blurb the talk about was about something else entirely — Customizing pre-existing software vs. Creating tailored, custom solutions with regards to web applications and CMS tools — and with that subject, as well as this new one, I was quite unsure that I was saying anything of any true interestingness…anything that actually needed saying.
My notion about who might be out in the audience whilst I talked was that they were brand advertisers or marketing people (potential clients) or agency creatives and/or stakeholders (potential clients and/or industry folks looking for inspiration) and that they had all at one time or another been vexed, frustrated, or curious about how the technical side of the equation worked.
You can feel my trepidation about how apropos or relevant my subject-matter was in my slide material…my thought was that if I wasn’t going to be smart I was at least going to be funny.
While I was encouraged and inspired by the amount of questions and positive responses I got to the talk itself, I was disappointed by the lack of laughs and giggles. I may have asked at one point “you guys can, like, see the screen, right?” So it goes.
My name is Justin Jewett, and I’m the Vice President and Technical Director at BKWLD, an independent digital shop located in beautiful Sacramento, California. We’re about 20-strong, and fairly evenly divided between development, creative + UX, production, and people who talk.
I’ve been at BKWLD since 2012; before that I owned and ran a small development firm called Rocket Society with one other person. We started that business right around the time that people first started hearing about Google. Five years before Facebook and seven years before Twitter happened. I’m pretty old.
My theory about how I learned how to be a Technical Director is simple: I did things the hard way, the wrong way, made mistakes, and close-called my way through a dozen years as the business end of that two-person development shop. My connection to the very technical aspects of hundreds of jobs over that time, combined with my intimate knowledge and reliance on the practical facts and drivers of those same projects — from a business and financial point of view — gave me the unique perspective of a Technical Director.
As natural as that point of view feels for me, I have found that it is quite unique, often misunderstood by my counterparts up- and downstream, and across the table with clients.
So I figured I’d talk to you about it for a while.
The whole idea of having someone on your staff who directs your tech is pretty strange. When the job title is taken literally, it’s quite difficult to justify the position, to be honest.
It seems like you’re describing a person who sits above the developers on your team and directs them to do technical things.
It seems like you’re describing someone who bills hours against your development budgets but doesn’t produce anything in the way of development but maybe they do sometimes or maybe they’re like the head developer…it’s quite unclear.
It seems like this is a person who maybe spends more time in meetings ‘getting to the strategic heart of things’ than the rest of your development staff and then somehow communicates this out to them.
All that’s true, more or less. But the fact that the title itself is vague, nebulous, and carries so much unknown baggage with it is sort of a problem. Again: for bosses, delegates, and clients alike. Here’s the basic truth:
Good Developers Self-Manage.
Developers, programmers, database engineers, technical staff; all of these positions — and the people who hold them — have a stigma attached to them…that being that these guys and gals are the worst but they’ve got us by the balls so what are you gonna do?
As with anything in the professional world around us, this is a fair description of those folks who are doing their jobs poorly. The good ones, on the other hand, are delightful and efficient in light of being saddled with all this bullshit that people put on them.
Good, experienced, collaborative, and mindful developers are quite considerate about hitting milestones, managing their workflows, fostering a healthy environment of co-creation and contribution between themselves and their peers and at the bottom line do not need an entirely separate ‘talking guy’ to sit in their meetings for them.
Is it nice for them? Sure. Do they need it because they are not capable of doing it themselves? Eyeroll.
Non-Essential Staff.
My job is not a ‘need to have’ position. It is not a ‘get by’ role…it is a ‘get better’ role.
A Technical Director should not be looked at as a slot that needs filling if your development team is thriving, producing quality code at a desirable clip, and not indicating that they are a significant point of friction on your path to business growth and excellence increasership.
If it isn’t broke, don’t fix it.
Still,
With that said, there is a large growth- and #getBetter- opportunity associated with this position.
They can sit with company leaders, important clients, and/or potential hires and bring an expressly technical — that is to say that they can steward strategic ideas as well as formulate tactical steps — point of view to conversations.
If your agency is taking on an attitude of growth with regards to doing more development in-house, and you are feeling like your creatives might benefit from a coach or arbitrator sitting between them and the ‘computer guys’ then yes. Hire a Technical Director.
Not that it’s gotta be about conflict resolution, but, well, it is about that much of the time. Likewise, if you — an agency person — find that you’re working with an increasing amount of third-party vendors — you’re shipping your development out — then definitely think about this role…you need a bullshit detector. It is actually something that you do need.
Not what it looks like.
It’s my opinion that the ‘Technical’ part of my job title is there much more as a function of telling folks — internally and externally — what I’m not, which is strange, as you’d expect a title to be more about what you are. I don’t make the rules, man.
The fact is that my capacity as a non-developer technical person puts me in all sorts of different scenarios within our entire business…my actual whereabouts and subject-matter are constantly shifting, forever changing, and perpetually in motion.
But! You can depend on the fact that I’m almost never designing, rarely wireframing or concepting flows, and never ever producing code. So there.
The essence of the position looks complicated and weird but it’s really not: I’m there to make sure that development — all the computer shit — isn’t just a bolt-on at the end. I’m there as a facilitator and integrator. I’m the guy you pay to make sure that you’re not being a fear-monger or neglecting the part of your business you understand the least. It works.
When I started at BKWLD two years ago, it was during a time of crisis…we were losing people and staring down the barrel of a seemingly insurmountable pile of work that all needed to get done at once. It was my job to try and see through the smoke and figure out what to do.
I did not approach this problem as a technician would…I really just tried to figure out why our people were frustrated and how we could start making plans for execution that would involve cross-project efficiency. All of that was based on instinct and a sort of common-sense perspective that I was not supposed to rely on as much as whatever technical expertise I was supposed to have.
Sure, that instinct was borne of years spent developing, but I consider it — that technical facet — to be to my thought process what typing is to a writer. Just another tool for getting it done.
Since that initial time of crisis, I’ve helped steer the development department to a place that makes it a much more predictable and sturdy piece of a puzzle that — by nature — is wildly unpredictable, fun, and challenging.
My role has expanded to include a pointed emphasis on sales, business development, and my voice is a loud — even overbearing at times — one in conversations about the overall vision for our company.
I’m the Vice President, busy with all sorts of Vice President things, and that’s great. But I’m still the same not-very-technical Technical Director. Why the title? And why was I able to approach and kill these very technical-sounding issues while maintaining my ‘not-very’ status?
I’ll tell ya: I have a theory about that. I think the title is a problem…but a necessary one. I think this sort of title is a transitional thing — like how the Secretary of War eventually becomes the Secretary of Defense — that will start to fade out over time.
As titillated and engrossed as I am with talking about my own theories, I’m not gonna spend any more time on the title. I’m gonna tell you what I think this position actually does, and why that matters to you, O ghostly reader.
(Obviously I didn’t say that last part in Seattle.)
Dedicated point of contact.
One of the biggest ‘gets’ that this position can provide an organization — whether you’re spending money or billing hours — is a dedicated point of contact. It’s super powerful as a good old-fashioned customer service role. It’s complicated I guess, but there’s a very real aspect of me and my position here that is first and foremost an account person.
That means that I’m here to talk to clients — or subtly different, for clients to talk to — and make them feel better about the decisions they’re either making or asking us to make on their behalf.
It’s a pretty big deal, actually. Imagine having a foreman or contractor hanging out in an architectural firm and looking over shoulders, sitting in on meetings, reviewing in approvals and advising against a wall made entirely of glass that’s supported by a couple of straws. Valuable.
Not to mention all the work that the actual developers are getting done while they would otherwise be trapped in meetings and on conference calls to discuss high-level…stuff.
If you put and keep devs in too many meetings and they decide that there is no good reason they should be there, they will both a) not be as productive and b) eventually quit. I am as sure of this paragraph as I am that water is wet.
But back to all of the joy of talking about me with none of the guilt of talking about actually me. How do you make sure this person who’s now talking to all of your clients is the right person?
Firstly, you do not want this person to be too technical. You don’t want them to scare the client with big words, big concepts, and overlong explanations.
Marketers and clients in general are by no means unintelligent, but they are single-minded in that they want what they want. This liaison should be in tune with that — empathetic, even — and understand how to communicate scatter as cloud. Use words like ‘big’ and ‘good’ and ‘better’…‘performant’ is pushing it.
Additionally — another #proTip — if this person fancies themselves a wizard, there’s a very likely chance that they’re gonna end up doubling efforts with your lead dev(s). I know to get out of my guys’ way…this lesson was hard-won and a total relief.
It is their job to be smart. It is my job to be TV-smart. Seriously.
But be careful: this person needs to know what they’re talking about. Just because they can render an idea into cartoons and simple shapes does not mean that they don’t know what they’re talking about.
If they don’t, well they’re just another person at the table saying yes to all the wrong things. Nobody likes this person because they are a yes person and yes people are bad people.
There’s an — obvious? — balance that needs to be struck. My team will often hear me refer to shit as being ‘jazz’ in this way and I really believe it.
A jazz person is someone who is intimate with fundamentals, knows their instrument intuitively, and can instinctively feel musical progressions and song structure. But that’s where they stop: they know enough to trust themselves to feel their way through it. They’re good enough to improvise…they used to hustle and now they flow.
A Technical Director needs to know when he’s talking to who and play the right song. I do realize that this has nothing to do with wizards and horses.
Right. Enough theory, yeah? Enough sermonizing and rushing to the middle-mark. You get that I think the ‘Technical’ side of Technical Direction is a necessary misnomer that sends mixed signals to everyone. You get that I think it’s important to zoom out and not forget the ‘Director’ part. Even though that’s the first time I’ve really said that.
I’ve been cautionary up to this point. But now here are some concrete, tactical informational points that you can use to form your understanding of what, what not, and who a Technical Director is to you.
There are a few things that — in my opinion — every Technical Director or high-level, non-developer, technical member of your staff should own. They are equally weighted in that each of these tasks should be done at all times with highest importance attached to each one. No joke.
Protect Developers
They protect their team, plain and simple. It’s sort of weirdly and sadly common to see developers and technical folks get mis- or underrepresented in creative agencies and in other marketing settings, which is a bummer, since they’re the part that brings the thing to life.
As a Technical Director, you’re there to protect them from this mistreatment — which, to be fair, is almost always borne of misunderstanding or fear — but you’re also there to protect them from themselves: no curmudgeonliness. Be on the team. Think about it before you say ‘no’. Do not be the IT bully that other folks might expect.
Checks and Balances.
The makers in our organization — the ‘do people’ — are somewhat evenly divided up into Production, Creative, and Development departments, and each project that comes through the door is reliant on each department doing it’s thing in concert with the adjacent departments in order to get done, get paid, and be proud of whatever we ship.
As a Technical Director, you’re there to make sure that there are ample and deliberate opportunities for collaboration, that no one department is short-changing or misallocating the efforts of the other, and really, that everybody is being set up for success.
To be totally honest, our production people are great at this…but I’m there to make sure that there’s someone outside their purview to keep everything in relative balance.
Sell.
A Tech Director who’s not smack in the middle of your new business processes is being misused.
They don’t necessarily have to be your ringer or God’s gift to money or anything, but putting someone who has a tactical command of how projects work, how they’re finished, and how they’re delivered in contact with prospective clients via the RFP/Proposal process is a powerful tool. Keep a vision person close-at-hand, but nothing says “We’re serious” like a robust understanding of what a client is asking for, how you might do that for them, and a clear and concise description of what challenges will need to be addressed in order to get to the end.
There’s one very specific thing that I feel passionately about with regards to what you Technical Director does not do as a part of his or her duties. I would go so far as to say that it is their responsibility — and yours, as the imaginary person who keeps them in your employ — to hold the following as true.
They do not develop for you.
It doesn’t make any sense until it absolutely does. The simple reason is that if this person is counted upon as an asset that produces towards a deliverable or milestone, they will trend towards that production, be relied upon, and become a full-time developer on your staff.
The less obvious but more important answer is that you want this person to go into meetings with a clear head. They should not be motivated by fear or self-doubt; they should be confident in their team’s ability to bring a vision to life…even if that vision is ambitious. To that end, this person should not be sitting there wondering if they’re personally up to the challenge…it will affect how they think, how they talk, and how they represent options to others in the conversation. This lesson was hard-won and a total relief.
Ok. So now you know what they’ll be doing with their time. But what are the qualities that (I think) make for a good fit with this job? So totally polite and accommodating of you to ask.
A leader.
Leaders who talk about being leaders are…something. But still! This person needs to be possessing of a quality that — once they’ve earned the trust of their immediate, adjacent, and even cross-table counterparts — causes people to want to listen to things that they say and then do something. It’s totally ridiculous to be talking about it in this way but it’s the truth and so let’s move past it. You’re looking for a leader.
A strong communicator.
This whole job is about communication. Communicating to the non-technical people what the technical people have concerns about in a way that they can understand; communicating to the technical people what the non-technical people want out of them in a way that is not absurd; communicating to (and fro’) clients in a way that translates dollars to sense (see what I did there?) and, well, doing it in an understandable and relatable way.
Verbal as well as written. Contractions. Possessives. Apostrophes. Grammar, son. Be so good at saying whatever it is you’re saying that it seems like you did it on porpoise when you make a typo or misspeak. Talk how you write and write how you talk. Seriously.
Funny.
Not really super popular in my line of work but yo: I find the internet, marketing, ‘apps’, advertising, messaging, calls to action, content, and anything ‘experiential’ deeply ironic and darkly funny. I feel that way because it is. It’s true.
Contrarianism aside, I feel that it’s important for a person who is often considered to be a keystone in solving big scary problems with lots of money attached to be a funny person. They need to have a sense of humor. For one thing, it will add to their memorableness and create a hook for when the proposals are spread out on the table and it’s time to pick one.
But another, more important thing is that it will truly and genuinely put people at ease. Break the ice and imbue confidence by showing each and every guy or gal on that conference call that you can answer their questions by stringing together a series of Beetlejuice one-liners.
They will either love you or hate you for it, and if they hate you for it, that shit was gonna come up sooner or later. Better now.
No.
Understanding when, why, and how to tell a person that they are not going to get exactly what they are asking for from you or your team is an incredibly important, desperately underrated skill that all client-facing functionaries should have.
It is not easy, and it is important to be sure you’re sure before you commit, but in the right context, one carefully and considerately dispensed ‘no’ can count for a fistful of yeses.
They often don’t think that they do, but your clients, your team, and your bosses all want guardrails. Nobody knows what they’re doing. Nobody knows what they’re doing. Remind, comfort, and guide them by suggesting viable alternatives to the problematic approach that they’re taking and they’ll thank you for it.
A skeptic.
You’re in a creative industry. You’re involved with making something. You’re surrounded by and surrounding yourself with people who believe. People who want to believe.
Find someone who doesn’t automatically believe. Be someone who doesn’t automatically believe. There are enough of those people at the table. Be an open, kind, and considerate skeptic. Make the idea sing for its supper. The work will be better, and this person (when did I start talking to ‘you’ the prospective Technical Director and not ‘you’ the supposition-seeking creative entrepreneurial marketing stakeholder?) will become a checkpoint for any big decision. Which is ideal.
That probably covers the touchy-feely side of this person’s (you again?) makeup, you think? Their technical qualifications can be summed up easily. Broadly, but easily:
This person seeks patterns in the professional phenomena he or she experiences. They look for connections-as-coincidence in things from a speedier-than-usual or a more sluggish-than-hoped dev build. They look for recurring rhythms in proposals that work vs. stutters and stops in proposals that don’t work. They recognize that of the five times they tested the theory, it was thrice beneficial to get production involved before discovery started as opposed to after.
They also — ideally — know how to do something with this information.
A system can be as simple or complex as you want it to be, but at its heart it’s a solution to a problem. Someone who seeks and identifies patterns of recurring problems or opportunities and creates workflows and or expectations for how to facilitate the solution or exploitation of those occurences is who you want.
This can be as mundane as ordering extra chips when getting sandwiches for their team because they know they’ll get eaten to as batshit as defining a series of rapid-fire data models that will get a backend up and seeable instantly but without any of the baggage of a pre-formulated CMS product.
Eyes up; ears open -> now do something about it.
This intelligent and observant and clever person will try it your way if convinced that there’s a good reason to do so. A ‘good reason’ is not necessarily qualified as you wanting them to, nor will they be frustratingly stubborn and/or unreasonable about defending the legacy of their tool in lieu of serving the solving of a problem.
They know that right and wrong has desperately little to do with you or them. They’ll probably make sure you know that too. It’ll sting but in a good way.
Finally, this person shares, supports, and can communicate your vision. This quality is not required of all your functionaries (I’m back to talking to ‘you’ the maverick intelligent amazing prospective client, aren’t I?) but it is definitely something that someone you’re quick to put in front of clients and have running triage on your teams should be able to get with.
This is as much for them (the Tech Director) as it is for you (you): it’s nice to fight someone else’s fight. It helps to have it also be sort of my fight because I’m indoctrinated, but if it was all the way my deal, I’d have a Technical Costrategist of my own and spend my time on jets. Jets.
You want someone you can trust to put your mojo out into the world in a style of their own. Not the other way around. This one is…important.
In closing…
It is no less awkward to say that in writing as it is to say it into a microphone while on stage.
Not very technical.
This Technical Director person really only needs to be more technical than you, the person who’s hiring them.
The person you’re looking for is not wearing Google Glasses. He may or may not be interested in an Apple Clock Bracelet or be passionate about optimizing left joins or necessarily even care what ‘SVG’ stands for.
He or she cares about teamwork, workflow efficiencies, morale, and seeks a deep understanding of the strengths and weaknesses of his counterparts. Client needs and requests are treated with care and are approached thoughtfully, but are not held precious or at odds with true solutions to stated or discovered problems.
They are more than just a computer gal/guy. They are a multidimensional, multifunctional, and multifaceted actual person who will entrench themselves at any place in a project or process that needs a breaking or shaking voice and say things that they believe.
They will adopt and even embrace the necessary outsider perspective that’s needed from them and learn how to communicate with you, your team, and your clients in a way that at once challenges your point of view and pushes your organization to do better, more dependable, and ultimately more profitable work.
Find a person who surprises and delights you with their practical approach. Put them in a position to affect change and be open and honest with them about how that’s going. Weird to say about a technical person I know, but it’s going to help a whole hell of a lot if you enjoy this person and they enjoy you.
Proper Integration will produce results.
If you — my maverick — can find this person, see them for who they are, and set clear and measurable expectations on this person, all while — this is the important part — avoiding boxing them into being just a talkbox for your devs, you will see marked, positive change to your business.
If you — my aspiring Technopundit — can manage to be found by someone with an open mind about how to use you and are put in a place where you can influence more than just daily development, do not disappoint them. Steward your departmental responsibilities with zeal, and find useful and clever ways to augment the larger business with your experience and personality. Be respectful but do not be timid…they don’t understand you so help them understand you.
So long and Thank you.
I had such a good time preparing this talk, building the accompanying deck (95% of all material is irresponsibly but good-naturedly sourced from Tumblr, btw), and writing this subsequent recap. If you have any questions, comments, or objections, please feel free to contact me here.
