Engineering-driven development
There are many formal development methodologies and a couple of informal ones. At the end of the day, it all comes down to the multidisciplinary teamwork and collaboration.
In an enterprise environment, there is always a difference between a formal process and reality. In reality, the routine how a piece of digital software product is ideated, developed and shipped is not necessary aligned to what is defined on the paper or what the company leadership believes is happening.
One of the most common differences between the formal process and the reality is a method that I call engineering-driven development. This happens when the whole product lifecycle is initiated, defined and executed as a one-dimensional engineering exercise.
Look it’s already done — What do you think?
This is a frequent hostage technique that I directly witnessed a number of times. A diverse group of functions across multiple teams and even business units is a having hard time to negotiate the design of a common component spanning across multiple products with its bundling and pricing model, user interfaces defining the final experience and technology stack responsible for the performance. As the real-life politics is teaching us every day, life is not black-and-white and it involves frequent communication with a lot of people, where different and conflicting standpoints are discussed and ironed out— from technology to marketing through pixel pushing and branding. While there is always an opportunity to introduce more structure into this collaboration, it’s mostly engineers that feels that someone is wasting their time on boring meetings. The time they could spend coding.
So one brave engineer rolls up his sleeves and takes a stab.
He throws his current tasks under the bus, sits down behind the machine and codes and codes. All day long, all night long, all weekend long. Then he organizes a meeting where stakeholders are called to sit and watch. He presents a solution. A solution that now exists and somewhat, works — it’s a running code committed into a regular source base. Everyone can clearly see issues and limitations, but hey, we have moved from theory into reality and these details can be fixed and polished later in an Agile fashion. Especially when the brave engineer presents the outputs as a “20-minutes quick side project”. Where are you now, all the bureaucrats and stakeholders that do not commit code? Product Owners, Designers, Marketers, Technical writers — all of them are just blah blah, but this is Lean & Agile & stuff. Now, let’s talk about this real thing — What do you think about this?
This brave engineer just applied his problem-solving framework to a problem he was able to identify — too much talking, too little output. History teaches us, that if a solution was not specifically and mindfully designed to match specific people goals backed up with factual data, and at the same time, it was not aligned with a clear business goal, no amount of iterating, fixing and polishing will turn a hackathon MVP into an uncompromised product that enhances life of many people.
It’s a company culture that has to change to avoid these moments before it’s too late in the process. The company has to value multidisciplinary collaboration over shipping. This organization needs to spend a comparable amount of time improving its ideation, collaboration and design process that it spends improving its development throughput via Agile and SCRUM frameworks. Organization also has to support a mutual trust across all the disciplines and functions and create an environment, where this brave engineer will approach a Product Manager first to validate his idea from a business perspective, then talk to the Designer to define a user goal and interaction, and only then spend precious company resources on code. Especially in an enterprise environment, the individual accountability for a half-baked result is not entirely transparent, so above setup is often only possible to achieve with a healthy amount of formal procedures, rituals and reporting structure.
It would be great to have this
This is another famous method that is part of the engineering-driven culture. It starts from bottom up, where a brave engineer clearly recognizes an issue — too many internal user requests are generated to create a new project in Service-X that falls on his head. But Service-X provides a very rich API, so all these requests can be automated. So what about building a self-service portal and let the users handle requests by themselves? This looks as a clear win-win, so let’s code it first, and productize it later.
The missing piece here is, that even that the idea makes sense, it is clearly not driven by real user needs that are matched to the global business goals. It’s driven by the repetitive and boring work that the engineer wants to automate and as a coincidence, he assumes that it will also make happy many other humans. It might come as a surprise, but very rarely this matches 1:1 the Users and Business goals.
How do we know the end-users, people requesting Service-X, will prefer this new service channel over the one that they are using right now? How do they choose from multiple available channels? What if they will simply not adopt it? Is this the best use of expensive company resources compared to other priorities that are generating the revenue and paying the team salaries? Who will maintain the final artefact after original authors move on? Who will take ownership for future improvements and change requests?
These are just a few questions that can be answered before a single line of code is written. But obviously, it involves a trusted communication between multiple disciplines that involves multiple individuals, and yes, meetings.
In engineering-driven development, engineers are encouraged to submit ideas in form of code to avoid the perception of coding monkeys or factory workers that are only being told what to do with no direct impact or influence on the ideation process or business priorities. But this is the root-cause of the problem that the organization is having — it is missing a structured approach to design process where indeed, engineers play absolutely crucial role and they have plenty of room to directly influence and steer the design process to the right direction.
Conclusions
Using design to learn means allows the business to gain insights to better inform product design and technology decisions before investing heavily in the software development. Design Driven Development by Jess Eddy.
A lot of organization are still obsessed with “Agile” as a formal process to ship more code more frequently and they are frantically obeying the up-front conceptual work as waterfall — forbidden and evil word. It’s interesting that even developer community is asking for a more structured problem-solving approach and recognizes the Agile gaps and benefits of techniques such as Design Studio, even that the formulation and and understanding of the full structured design process remain vague. It still assumes that complex problems can be solved on the spot during a few days workshop, not as a lasting activity deeply integrated into the organization heartbeat and day-to-day operations.
We had come prepared; our UX designer and project manager both have industry experience and they had interviewed several customers who might use the feature set. Developer-driven development by Isaac Lyman for Hackernoon.
Structured and well defined problem solving frameworks are available for any organization to adopt — from Cooper’s Goal Directed Design to IDEO’s Human-Centered Design process. These frameworks needs to be deeply embedded into the organization structure followed with a formal project governance. For example, no code is created without product management prioritization, design research and validation, off course in the same way as no design is ever made in form of a daydreaming picture without engineering and technical function’s direct input — even in a form of MVP or throw-away code where appropriate.
With healthy ideation processes that allows experimentation, validation and throw-away work, there is no need for corporate hackathons and fake internal Startups, that are just an excuse to obey existing project governance and processes that are clearly malfunctioning. Current modern UX Design (or Interaction Design as Alan Cooper properly refers to our role) domain is ahead, equipped with many proven, structured and well-documented techniques not only to participate in the project governance, but directly lead the process on the executive level. So dear Enterprises, you not only need to hire more designers to make your UI pretty, you need to empower senior designers to make executive decisions, influence the organization structure and establish a well-balanced triad roles on the executive level.
Interested in my thoughts on common Agile Traps? Continue reading with next article.
