Hello, my name’s Chris Landtiser, and welcome to Front End Center.
This episode, I want to talk about value. Creating value, and then communicating that value, is at the core of most creative work. In some cases, that can be a simple proposition; a commissioned project with a clear deliverable, or a maintenance request to fix a bug. Unfortunately, this kind of work doesn’t often make a great platform for growth.
The biggest opportunities I’ve had in my career have been larger, nebulous affairs. They started as unfocused ideas and obtuse goal statements. There were two parts to every scenario:
Identify and deliver the value the client wants to gain.
Communicate the process and final product’s value in an engaging way.
Many developers are spectacular at part one, the technical delivery. I know a lot of developers, front-end and back, that could code circles around me. Yet, when searching for freelance work or a new team, they have trouble making their immense value apparent.
There isn’t one skill that makes value identification and communication just click. Vocabulary, strategic planning, inter-personal conversation, and plain old brute-force experience are important, but still not the whole story.
The biggest problem is that there’s never just one type of value to find. You need to consider the end goal, and what stake each of your interactions has. If you’re bidding on a project with the goal of “Make all the money”, that’s going to mean very different things to the owner of the business than it is to the head developer who makes first-round contracting decisions.
My first exposure to this process was working in electronics retail. It’s amazing what a healthy dose of retail experience can teach you about life. The value here was the exposure to customers who knew exactly what they wanted, or had no idea what they wanted, or had come to the computer department looking for a TV remote that would let them control the Facebook with their iPhone.
For all that complexity, I had a preset number of solutions sitting on the shelf. It was up to me to identify a need and identify what came closest to meeting those needs. Sometimes I got pretty creative and helped architect some very interesting DIY projects, but ultimately I had a limited pool of what I could do and provide.
When I took those skills and began to apply them to my own design and development, it was pretty exciting. Suddenly, I didn’t have an artificial selection of goods and services that I had to stick to. I could engage a client in any business (in theory), and the only limits on what value I could provide were my own knowledge and effort.
This leaping off point is also the hardest time to make your value clear in client interactions. Many people that freelance early in their careers are learning their technical skills at the same time as they negotiate work.
When you’re still getting the hang of new technology and its benefits, it’s tough to act as a buffer between the work and the non-technical client you’re doing that work for.
Against popular industry advice, my first few freelance projects were for local restaurants, among other local businesses.
The owners I worked with were text-book non-technical clients. They already had their hands full managing a complex business that required marketing, procurement, food knowledge, payroll handling, and more. The technology innate in even a simple website was beyond their scope and, honestly, interest.
These types of clients represent one extreme of the spectrum, the non-technical. The other end includes interactions like a job interview with a technical peer. Someone who understands the innate value in the work you do, and can find worth in the technique itself without having an immediate purpose.
Both ends of the spectrum represent fairly simple ways to present value. A technical peer shares an empathetic specialty and position, as long as you don’t get completely stumped about what you claim to know.
To address value with a non-technical client, questions are your best friend. They don’t know technology and you don’t know their business. They know what they want, though, and usually have at least general business goals in mind.
Showing value in this case is as simple as moving them closer to that goal than they could have been without you. Don’t get bogged down in the JavaScript you used for their photo-slider or how the design follows the latest trends in a specific design ideology.
There’s more ways to aid that value demonstration than I can cover in this podcast, and they depend on the client. “How did you find us?” questionnaire cards, web Analytics data, and a sudden, otherwise unexpected uptick in profits are all potential places to start.
There’s a wide band in the middle of this spectrum, though, that you begin to see when you work with larger and more complex projects. I got a taste for the differences while working in a startup team, but have seen them in detail in an enterprise role.
This middle spectrum is made up of professionals who work in parallel to your expertise. They may be the back-end developer to your front-end. They might be a manager who hasn’t actively developed in years, but was pretty sharp when they WERE in practice. It could also be a high level stakeholder that’s never developed before, but is intimately familiar with running a technology-centric project.
To adequately communicate value in these interactions, we have to borrow from our lessons on the bookends of the spectrum. We need to lay a foundation via questions and find out what’s important to highlight. Then we need to back up that value with a certain amount of technical prowess, as each case demands.
When working on a large scale application with a backend developer, I’ll often search for stress points in their own work. If they’re having a hard time meeting the business-mandated loading time, and I can save them fractions of a second via some careful JavaScript, I bring that front and center. If they can grasp the work you’ve done that made their job easier, you’ve scored a huge win.
The most complex and difficult time to really communicate value is right at the start or end of a project with many external influences. A kickoff or wrap-up meeting that involves three developers, two managers, and a Chief Officer from outside your team is an odd place to balance your value-pitch.
On one hand, a polished presentation and slideshow will probably allay most questions and wrap things up on time. But then you’re left finding out who did and didn’t understand your value for the next few months or years as they question your work.
My only advice is to try a similar approach to a genuinely non-technical client. Use questions and interactive conversation to understand the value needs from as many perspectives as possible. It’s a bit of a juggling act, but the more needs you can tie together to solve in one large swoop, the bigger an impression you’ll make. Decorate with technical-detail-glitter as needed, and you’ve done everything you can to communicate the value.
There are college degrees and career fields focused just on how to communicate ideas like value correctly. Being aware of these basics, though, can put you head and shoulders above competition for freelancing or team hiring. Next week we’ll be looking into some more code-related ideas involving Cascading Style Sheets and development scaling.
Until then, though, this has been Chris Landtiser. Thanks for listening to Front End Center!