Development should start in the boardroom.

I’m quite a passionate person, but don’t ask my wife, just take my word for it. This means I struggle to “just do my bit“ and let you do yours without sticking my nose in somewhere. Overarching visibility and awareness of the wholer-whole is important to me and something I believe to be often undervalued in engineering teams. Maintaining that sticking-your-head-over-the-fence attitude has always given me something incredibly valuable; perspective. Why are we doing this? What does this achieve? Why are we spending so much time on this one thing? Couldn’t we do this instead? Is this annoying? Probably. Does it make me a better developer? Potentially. Will I stop?

Never.

We developers are an interesting bunch. Doing this job for as long as I have has exposed me to people from all walks of life, and from places all over the world with a vast array of differing, sometimes complimentary, sometimes conflicting, perspectives. One thing we do tend to have in common, though, is an ability to solve problems, much like a good business. All too often this pool of problem solving individuals are omitted during arguably one of the most critical phases of a product lifecycle, inception. I’ve worked in plenty of teams that are only brought in once the business has already cemented their decisions and begun moving in their chosen direction. By the time the actual implementation task has filtered down and landed on the desk of a developer, it's all too easy for any context to be lost. It's not easy to convey the true motivation and business objectives of a particular task into a Trello board (is that still a thing?) or Jira ticket, nor is that really the place for it.

I believe there are 3 main reasons that developers should be brought in earlier in the feature lifecycle.

Firstly, the technical. These individuals know the nuance of this products codebase inside and out. Quite often, whilst working on a particular aspect of the application, there may well be additional features or enhancements that are fairly quick to implement whilst “in the area” which can add value to the end user. These aren’t always intuitive, and often seemingly complex pieces of functionality can be achieved with relatively low effort. Conversely, a seemingly trivial addition may have far-reaching impact on the codebase, requiring complex, error-prone modifications. Perhaps there’s a “diet“ version of that feature that can be implemented more readily with much a lower impact? With the right analytics, the business can decide further down the line whether implementing the “full fat” version is worth the investment and risk. The only people who can offer meaningful insight into the code are those that wrote it, and having that immediate “that’s easy” or “that’s challenging, but how about…” feedback can make a huge difference to the velocity and productivity of a project.

Secondly, developers are people too, and, as I said previously, a diverse bunch at that. Plus, we have experience using technology as both a consumer, and a developer, which provides an incredibly unique insight. Once you see the world of technology through the lens of a developer, it’s very hard to go back. You can almost visualise the code running behind the scenes, and often feel as though you have some innate understanding of its inner workings (or the complete opposite, in some cases). Because of this, you tend to get a pretty good feel for what’s been written well, and not so well. Those unhandled errors, clunky integrations, meaningless progress bars, or unnecessary network dependencies all become all the more jarring. Many of these bumps may go unnoticed by a non-techie and just add up to a negative overall experience without them really identifying why. To us, though, these things stick out like a sore thumb, leaving a lasting reminder of how-not-to-do-that-thing. This, of course, is incredibly valuable when fleshing out new features and navigating UX challenges. Having that unique perspective can help the lesser technical roles within the team better understand potential pitfalls of particular implementations, and help guide the decision making process toward a more user-centric, more polished outcome.

Lastly, it’s a great way to cultivate a team of people that give a fuck. I can recall countless times I’ve been required to implement something that just doesn’t sit quite right. Maybe it’s just a bit clunky? Maybe it’s technically more difficult than that of a slightly augmented approach? Or maybe it’s sitting a little too far toward the morally questionable end of the spectrum? Whatever it is, feeling like you have no influence over the direction of the business or product isn’t a great experience as an employee. People want to be proud of things they create, and rightly so. Empowering those who will ultimately experience the decision-making outcomes by involving them in the process fosters confidence in the team, the processes, decisions, and, ultimately, the product. This approach nurtures a culture of care for their work. Moreover, providing context can help the engineers really understand why they are implementing these features and the motivation behind them. This will improve clarity and understanding, ensuring the feature doesn’t just check the objective “does it work” box, but allow them to build and test in such a way as to ensure the desired value is added, and objectives met.

Now, of course this is all great in theory, but it’s not always practical to implement. Engineering teams can vary greatly in size and structure, and whilst I’m sure summoning the entire engineering team to the boardroom to discuss where the “contact us” button should be is a great way to get shit done (/s)… the benefits I’ve outlined above should not be underestimated. There are an infinite number of ways to approach a particular challenge and excluding a wealth of knowledge, perspective, and expertise at the most important part of the product lifecycle is woefully underutilising one of the most valuable assets your business has.