Engineers Are Your Best Designers
Everyone who’s worked at a technology company knows the way product designers and software developers are different: they often have varied skill sets, divergent responsibilities, and, in many ways, their brains just function differently. Since designers and developers are so dissimilar, it makes sense to keep them separated on projects.
Right?
Traditionally, we would create a specialized silo for each separate activity in a multi-step process and assign specialists to focus on each of those independent steps. This was, and still is, a fairly popular assembly line approach to a manufacturing process.
The key word above is manufacturing. If you’re producing thousands and thousands of units of the same product, all based on a single blueprint, that approach is terrific, still to this day (except, of course, there aren’t as many humans involved in the assembly line work anymore).
Let’s move on to the modern world of constant technological innovation. Innovation, by definition, involves the creation of something new, — generally a somewhat custom, one-of-a-kind digital product. The most straightforward thing here is to apply that same familiar assembly line, waterfall approach to it.
Well, this doesn’t look right to us — and to most companies out there. The Agile Methodology has become the answer for many, resulting in companies adopting the rapid and flexible, sprint-based schedule within the development team.
While it is inspired by Agile, it can hardly be called a truly Agile approach since it does not add all that much agility into the business as a whole. With that in mind, many companies go further and extend the sprint-based schedule outside of the development team, and include product management and design groups.
Sadly, very often that’s the extent to which organizations see the Agile approach. Yes, now you can enjoy the agility of running the product teams in a way that makes it easy to learn from the market and change the course fairly rapidly.
However, the actual workflow within the sprints is still essentially an assembly line — often with deliverables thrown from one specialized team to another “over the fence”. While at Ford’s production factory floor the assembly line work was encapsulated purely within the manufacturing (“implementation”) stage of the production process—efficiently producing the same product over and over again for years, the complexity of modern technological innovation work calls for what Agile approach is truly about. It’s not so much about scheduling the work in 1–4-week chunks (which, of course, does give the desired flexibility to the business), as much it is about making the right decisions based on the data gathered and contributed—essentially doing the right work—collaboratively.
I am a true believer that the true power of the Agile approach is only realized when you bring different people, who are diverse in their background and skill sets, — from all parts of your organization — together.
At Handsome, we break down the silos and let members of our product teams build things together, which includes engineers working in lock-step with designers.
We include engineers to be a part of every phase of a project, which allows them to fully understand a client’s vision, business needs, and timeline requirements. They also get first-hand access to understanding end user’s needs, building a significant amount of empathy into the product development process.
The benefits of adding developers to your design team don’t stop there, though.
Define the Right Product, Together
It’s well-proven: you’ll have a higher quality product if a more diverse team builds it. I’m not just talking demographics — diversity includes the breadth of past experiences, skill-sets, approaches to solving problems, and even varied mindsets. Yes, designers and developers are often looked at as opposites — which is why they complement each other extremely well. Developers will naturally try to get answers to questions that designers may not think of, and vice versa.
Since an engineer’s main responsibility is to build a product, they’re the perfect companion to those designing the experience. They’ll ensure the feasibility of design ideas and concepts, and introduce creative tech-thinking that empowers the design process.
Build Right The First Time
It’s not just about the right product being built, it’s also about building the product in the right way. With all the right context — user needs, a client’s goals, business limitations — developers can make better engineering decisions from the start.
If developers are siloed, they may end up building things that set a product up with unintended future constraints. With the right context, they can better build codebases that allow for flexibility when needed. This is especially important when building an MVP — especially since every 3 out of 4 startups end up pivoting, according to a recent EPFL study.
Work smarter, not harder. Write the right code, not more code. Within the right environment, these theoretical principles become a realistic practice.
Encourage Ownership & Decrease Management Overhead
When developers know the why behind an ask, understand business needs, and work empathetically with users in mind, it’s much easier for them to own the solution they’re building. This new kind of accountability isn’t mandated by a manager, but rather comes intrinsically from the developer themself.
Engineers will already know what needs to be done, and why it needs to be done, without having to question — whether consciously or subconsciously — certain product decisions. No longer having to micromanage execution, team leaders can focus on helping build the right framework to ensure engineers are most productive and efficient.
Increase Empathy Within The Team
Eliminate finger-pointing and sending deliverables over the fence, which often happens when developers are stuck at the tail-end of a project. When your team is set from day 1, each member will have more empathy for one another.
This structure leads to more natural and effective collaborative problem solving. Interpersonal challenges also get resolved more easily when your team is all following the same North Star vision.
Increase Employee Happiness And Retention
Many engineers get burned out or bored at work because they don’t have any visibility into what happens after their code is written. They’re disconnected from the rest of the process, and much of their work may end up seeming pointless. It’s in our nature to want to make an impact, solve challenges for people, and create something that truly matters. You only get to feel this as a developer when you see the full picture starting with a user’s needs and pain points.
The need for self-actualization — from the top of Maslow’s hierarchy — should never be discounted. Despite being the highest paid employees at many companies, it’s the sense of fulfillment a developer gets from the work that often makes them want to stay, even if they’re building what may seem to be a boring B2B app. Understanding their user’s story and the why makes all the difference.
There’s no silver bullet or a universal way to embrace this workflow, and it will vary for most companies. Not every project will need an engineer along for each step of the process, and, from a purely short-term economics standpoint, it may seem expensive to pay an engineer to do anything other than code.
However, challenging the typical assembly-line approach to digital product design and development by truly integrating design and development functions can unlock award-winning ideas for what could otherwise be just an average product.
