An executive recently confided in me that he was surprised to learn that developers cared what problems they were working on. “I thought they just cared about writing code, not what it was for,” he said, in what seemed like newfound respect.
While this might seem like an isolated opinion, many technology leaders direct their developers in ways that support this statement, even if they wouldn’t put it so starkly. Developers are often seen as interchangeable parts who can go from working on internal tools to email templates to site reliability to API development without a second thought. Further, the tools and processes we use strengthen this view; tickets are often assigned to teams who align on a certain skill, not a given product or problem set, and organizations are often delineated by understanding of a portion of a “stack” (front-end, back-end, APIs, etc.)
These distinctions make some logical sense (I’ve recently been guilty of organizing teams by these assumptions) but to foster true creativity, new techniques will be required.
More than any other technique (and I’ll write about others in the coming weeks) the one that must come first is to realize that development is not about writing code, but rather using code to solve problems. Too often tech teams are given tasks without context or goals, cutting off an avenue for innovation and creativity. With clear communication and trust, we can unlock the creativity of our tech teams by treating tech as a strategic partner and not a service bureau.
This begins with sharing strategy, goals, measurements, and reasoning with technologists, including everyone from the CTO to individual developers. Recent history is flush with examples of developers and engineers creating new lines of business within their organizations; Amazon Prime is likely the most successful of these. These contributions were only possible because these developers understood their company’s goals and could apply their unique skills to those problems.
Unleashing this creativity requires clear, candid communication. Only by sharing hopes and fears honestly will every member of your staff be in a position to contribute with all of their skills.
Once they’ve been properly briefed, developers tasked with solving a given problem should work together across boundaries of expertise. Whether you call them teams, squads, pods, whatever, people working together to solve problems will yield solutions that are both more creative and implemented more quickly. The tight feedback loop of design and interface development, or API development and information display, for example, creates this effect. If at all possible, this should include participation from design, product development, and even editorial and marketing, if appropriate.
Treating technologists as service practitioners will guarantee you get exactly what you ask for. Including technology in the early stages of defining problems and opportunities will mean getting solutions far more creative, efficient, and sustainable than you could have imagined.