What is technical strategy and why do you need it: DrupalCon Portland 2022
Speakers: Dave Hansen-Lange and Heather Wozniak
There are two significant changes in the past decade that should prompt us to think differently about tech leadership in web projects:
* Websites can now live forever (enabled by Drupal 8, proven by Drupal 9)
* We now do a lot more upfront strategy when building a website (organizational strategy, content strategy, UX strategy, etc.)
Most web projects have a “Tech Lead”. Historically, that role has had two main responsibilities: Turn ideas (from designers, UX, etc.) into a technical plan, and then lead the development team in creating it. This has worked well in the Drupal community for “the big builds”, but once a project transitions down to a lower level of ongoing changes, it becomes insufficient. At its worst, website “support” is a purely reactive enterprise: client puts in a request, developers make it happen. But in that arrangement all of the up-front strategy can easily be lost. If the website lives on for years in this state, there will be a growing frustration that the website is not able to keep up as the organization evolves. The website will end up being torn down, and the cycle started afresh.
It doesn’t have to be this way. Let’s think about how we can reenvision technical leadership to counteract this phenomenon. We'll explain how we approach technical strategy at Four Kitchens and how this has improved the effectiveness of our clients' websites and the experience of their users.
There are two significant changes in the past decade that should prompt us to think differently about tech leadership in web projects:
* Websites can now live forever (enabled by Drupal 8, proven by Drupal 9)
* We now do a lot more upfront strategy when building a website (organizational strategy, content strategy, UX strategy, etc.)
Most web projects have a “Tech Lead”. Historically, that role has had two main responsibilities: Turn ideas (from designers, UX, etc.) into a technical plan, and then lead the development team in creating it. This has worked well in the Drupal community for “the big builds”, but once a project transitions down to a lower level of ongoing changes, it becomes insufficient. At its worst, website “support” is a purely reactive enterprise: client puts in a request, developers make it happen. But in that arrangement all of the up-front strategy can easily be lost. If the website lives on for years in this state, there will be a growing frustration that the website is not able to keep up as the organization evolves. The website will end up being torn down, and the cycle started afresh.
It doesn’t have to be this way. Let’s think about how we can reenvision technical leadership to counteract this phenomenon. We'll explain how we approach technical strategy at Four Kitchens and how this has improved the effectiveness of our clients' websites and the experience of their users.