Developer's Guide to Communicating Technical Value

Why does a developer need to communicate his or her value to a client?

When I returned to my undergrad alma mater a few years back to speak to the local ACM chapter about software engineering in the real world, the subject matter was not technical. I spoke to them about the value that they must add to their company. If they expect to step out of college into a $50k+ salary, then their work needs to add more than that to the company bottom line each and every year.

This declaration was daunting. College of the Ozarks allows students from lower-income backgrounds to work their way to a Bachelor’s degree. Most who attend this school aren’t accustomed to regularly dealing with even 4 figure sums. Asserting that an employer would expect them to be worth 5+ figures per year got their attention. I went on from there to talk about using soft skills to communicate that value without being a self-important blowhard.

I feel like it's worth delving deeper into this idea, but first I'd like to assert that enabling those on the other side of a company’s technical divide to implement business ideas builds the expected value really quite easily. If this wasn't the case, then developers would be out of jobs.

It’s not enough for the career minded developer to add this value silently; however. A person who has come up with an idea that was implemented by their IT organization will feel that she is responsible for the end result. She is correct. An implementing developer, even a lead or principal, is similar to a plumber or a painter: a skilled worker; maybe not easily replaceable, but not core to the project.

How does a skilled worker communicate his or her value to a client?

Reality for many developers in the corporate world is that requirements land on their desk after being filtered through JADs, business analysts, and project managers. The project will have already been sized and scheduled. The developer becomes a paleontologist, combing through the fossil record of the document to determine original intent.

In such a world, it is difficult for a developer to communicate her own value. Opening technical discussions with the business sponsor of a project, who will almost certainly speak from a viewpoint foreign to the developer, can cause unexpected consequences such as requirements changes and scope creep leading to project delays. This spurs some organizations go so far as to discourage or even disallow developers to interact directly with the business sponsors.

Even outside of this difficulty, trying to have a technical conversation with a business sponsor is often not the best way to communicate value. Imagine a painting contractor hired to paint your office trying to engage you about how the idea to use a paint sprayer in the entry hall was discarded because of the possibilty of paint getting into office workers clothing as they walked by. You'd probably agree with the decision, but you'd also probably think that should seem obvious for a professional painter and you'd wonder why you were being told. What if next time you bumped into this fellow, he tried to explain to you why they chose to use a matte paint? After a few uninteresting exchanges like this, might you tend to avoid that particular worker when you have a choice?[1]

If a toilet flushes, if a painted wall is without visible defects, if a customer pushes a button and the business collects $200 without passing Go, what does the client care whether about, for example, code littered with obtuse variable names? There are myriad discussions around this question in the long term. In the short term, outside of cost, scope, and schedule, I believe that it comes down to whether the client feels validated by her interactions with the skilled worker.

How does a technically minded developer go about providing validation?

Providing validation is an emotional rather than an intellectual exchange. It's not always natural for a technically minded individual to engage in an emotional exchange, and being on the giving end of such an exchange is even more difficult.

Here are some things that have worked for me.

• I engage the business sponsor about the project without adding anything technical to the conversation. My instinct is to tell them all about the clever way that I’m solving their problem, but what I do is listen to how their solution solves the company’s problem or meets the customers’ needs. The result is that the business sponsor understands that I care about the project. In doing this I took a small step toward communicating my value to the company. The bonus is that there is nearly a 100% chance of learning useful about the project.

• If a business sponsor engages me a technical discussion, I try to determine the true level of interest before jumping into the details of my newfangled tri-sub-optimizing architectural marvel wonder. It could be that she has a technical background and truly wants to hear about it in all its beautiful and gory detail. Or, maybe she is a natural learner, and she simply wants to expand the borders of her knowledge a bit. It could also be that she herself is looking to communicate her value, and she is looking for me to provide a problem for her to provide input on. I let her guide the conversation.

• I try to find ways to let the business sponsor provide more direct input. The ultimate validation for a business sponsor is to see her own ideas directly mapped into a system. Domain driven design is a great enabler in this respect. Where company culture does not provide opportunity to collaborate on a ubiquitous language, every little bit helps. For example, if a requirements document calls one concept a Flibber but you think of it as a Flooper, then change your terminology to match the requirements. Call it a Flibber in your code, from database columns to class names to variable names. When you speak about how the Flibber works, the business sponsor who provided the term will understand that her technical team listens to her.

Is this dishonest?

The key for me is in recognizing emotional exchanges for what they are. If you realize that a discussion is not an in-depth technical conversation, then you won't feel so strongly the need to provide the "actually"'s and "no"'s and other interjections that others may find abrasive. The right way to have the convsersation is to find a way to provide validation.

Even so, you must stick to your principles. An exchange like this must be earnest and honest. You have to believe what you say. Those business folk that you're interacting with will likely have a social intelligence that is much more developed than your typical techie's. If you're saying things that you don't believe, there's a good chance they'll know.

The key to these exhanges is to be nice, which means that you need to be nice.

Good luck :-)

[1] Please understand that the painting conversation examples are complete BS. If you are a painter yourself, then you will already know this.