Throughout technology around the world, software engineers and startup founders love to brag about their “technology stack”-- that is, the front-to-backend collection of programming languages, third-party libraries, database services and scaling infrastructure that make their addictive app snap to life or essential service run with a high level of reliability.
The choices these engineers make are the result of a near obsession with a few precious milliseconds that make or break user engagement, site traffic, and ultimately revenue. And it’s this obsession that pushes the software development community forward in pursuit of the perfect computing process (the effect of such processes remain up for debate).
In some ways, creating these technology stacks are akin to choosing education technology in a K-12 classroom--call it the "learning stack," if you will. Where the performance-obsessed engineer tweaks, researches, and remixes programming languages and coding practices, daring practitioners, like those profiled in EdSurge’s Day in the Life Of series, mix and match technology and pedagogy that might transform their teaching practice and students’ learning.
There are some differences, of course. Where a technology stack fails --perhaps generating the now-defunct Twitter "fail whale"-- social media users have other options. They can still connect via Facebook, Instagram, Snapchat, and others.
But when a learning stack fails--maybe when video isn’t optimized for a school’s broadband, for instance--students typically can’t simply click a link to the next learning environment. The resulting technology-induced disengagement triggers classroom management problems, lost instructional time and other unexpected barriers to students’ learning.
When 'Failing Up' isn't an Option
So how exactly should the time-strapped educator go about deciding which bundle of products and services might enhance their instruction?
Bold experimentation and learning from failure may be the most effective way to understand the many nuances involved with integrating technology and learning, but "failure" is often politically or professionally untenable. A more practical approach lies with educators improving their dialogue with edtech innovators.
An “edu-technical” language--one that describes classroom pedagogy and needs through processes and data--can force vendors and developers who lack understanding of a learning environment to share some ownership of students’ learning outcomes. Educators need not create technical schema (unless they want to do so). But when educators can articulate their needs through the language used in RFPs and sales’ meetings, they will be able to more clearly demand how technology can enhance learning.
Finding the proper “edu-technical” language to inform the learning stack starts with building consensus around pedagogical aims and understanding where data does or does not support these aims. The data is the glue in between the layers of the learning stack. When the data needs behind a specific pedagogical approach are clear and transparent, it becomes much easier to identify what current products fit into the learning stack and what products edtech innovators should develop for the future.
Every school may not need to develop its own learning stack--but it should aim to be fluent in edu-technical language.
Rise Above the Noise, Focus on Real Needs
The ways in which school leaders and practitioners turn data into actionable knowledge underscore technology’s promise to improve teaching practices and student learning. If a learning stack can’t extend the learning experience beyond its current capacity (those proverbial milliseconds in engineer-speak), then resources should be allocated elsewhere.
With a data-driven explanation of each classroom or school interaction, it becomes much easier to focus technology innovation on real needs, and avoid a scenario where new technology affordances-- lacking pedagogical or operational context --are stunted by confusing or unnecessary features.
To make a school more efficient, a learning stack at a minimum should eliminate overhead, reduce communications barriers and increase access to resources. When educators and vendors can find a common language (as proposed here through an “edu-technical” language), administrators can become better decision-makers, teachers can more readily apply their expertise, students can manage their own learning, and vendors can become measurably (gasp!) more accountable in students’ learning.
