How to Tie Your Shoes

This week marks the official start of the big corporate re-alignment project that I will be flying to New Jersey to participate with next month, and one of my colleagues who has been an integral part of the LMS project is in attendance for some of the preliminary, non-technical meetings that will set the tone and direction for the coming year. Given the high hopes a lot of people are pinning on this project, it's interesting to hear that the LMS that I've worked on over the last two years has been gathering a lot of attention. So much so that my colleague has been asked to deliver some demos and walk-throughs of the project and how it's impacted school operations across Japan. Given that he's been the main project lead since development officially started in 2016, this is an excellent opportunity for him to show off the fruits of his labours. However, as the sole developer of the system, people have reached out to me via email and Skype to ask a number of questions about the future of the project and whether it can be adapted to work for schools in different countries.

"Of course it can be adapted to work in other countries," I tell them. "It's just software."

Wearing Nice Shoes

A lot of people want to know what's next for the project and whether it can survive going from being developed by a single person to a team of people around the globe1. Some want to know whether something designed to be used in Japan can really be used in countries like Mexico, Colombia, and Switzerland. Others think it's an interesting concept, but wholly unnecessary given that we had software that sort of kind of did a small bit of what the LMS is capable of. What I find most interesting is that the questions being asked are the wrong ones. Wrong not because they're born from the typical tunnel vision that afflicts organisations around the world, but wrong in the sense that they skirt around the actual question that people are hinting at but never directly stating:

Why are people — particularly managers and teachers — excited about this tool?

It's this why that should be asked again and again because that's really the only way to understand why so much of the other software that's been created for this company by very smart people around the world has failed to live up to the needs of the people who actually do the work. This isn't to say that the project I worked on is necessarily better. From a technological standpoint, it's downright archaic in how it accomplishes its purpose. From a business process point of view, however, it's perfectly aligned. Considering how I worked in the classroom for almost a decade before developing the LMS with the support of some very smart people, this shouldn't come as a surprise at all. Too much of the software companies rely on are created by people who mean well, but don't fully understand how the processes, people, and cultures within an organisation mesh together to create the businesses that customers interact with. Or, in the case of my employer, students.

One of the key ideas that I hope to share with my global colleagues when we meet in New Jersey is this notion of asking why until we reach the real reason behind a project or a feature request. It's something a former colleague/mentor of mine taught me, and it's been incredibly useful over the years despite the plethora of software projects I've created that served nobody but me.

So here's a simple question: why do so many of us tie our shoes with a knot?

Taking this question all the way back will have us ask fundamental questions about the kinds of shoe we buy, the reasons we buy them, the goals we hope to accomplish, and eventually the reason we wear shoes at all. A lot of the people I've worked with — no matter how smart — have often stopped asking why at the first or second level. When it comes to solving complex problems, this is just not good enough. Problem solvers and solutions providers need to go much deeper than one or two levels. We need to reach the core. Otherwise, anything we create to solve a problem is just an incomplete idea.


  1. to add a little bit of fun, the project needs to change from being a self-hosted tool on a LAMP stack to being written to run completely within the Salesforce ecosystem; a platform I've never worked with. It should be interesting and lead to even better opportunities going forward.

We Shouldn't Be a Fan of Our Work

Last year, after almost a decade of circumventing rules at the day job to help people serve students better, I was moved out of the classroom and into a full-time development role to continue doing what I was doing as an instructor, but without all the cloak and dagger to make it happen. A lot of people were happy with the news, including myself. It meant that I could play a role in making something that colleagues all over the country might find value in, rather than something that just a handful of schools would use without really saying much to upper management about it. Over the last 15 months, though, I've come to dread going to work. I despise checking email. I want to be invisible on Skype all the time or, better yet, just shut the distraction down so that I can make it through the day without wanting to hurl a computer five stories to the pavement below1.

The problem is not with my colleagues. The problem is not with the endless complaints from people who storm into the little space where I do my work. Believe it or not, the problem is not even with the sound of silence from human silos within the organization who refuse to share their knowledge of the home-grown CMS my project must interface with. The problem boils down to a very fundamental issue that will never be resolved so long as I am working for someone else.

The issue is the result of an unsharable vision.

Steve Jobs and the First iPad

Way back in 2010, soon after Steve Jobs walked on stage and showed the world the iPad, I started thinking about how such a device could be used in education. By that time I had been teaching for almost three years and had the hubris to think that I could write software for a tablet that would make education easier for teachers, students, and all the support staff that are required to make a school function. Looking back at the early design sketches, I almost cringe at the naivety on display. The concepts I was dabbling with were far too similar to the way Microsoft approached tablet software in 1999.

Suffice it to say, the sketches went nowhere and I shelved the idea for a few years, revisiting the idea whenever I'd read an article about how tablets were being used in education.

Fast forward to 2013, I was asked to create a special kind of report for a new type of class that was being trialled in the area. Excel was a mainstay at the day job, and every report we gave to students or their sponsor came from this spreadsheet software. Me being me, I was one of the few people responsible for writing all of the reports in the region to ensure that every student and every sponsor would see a consistent message with consistent formatting and consistent quality. This new kind of report, though, needed something that Excel was not particularly good at without a complex series of macros. Instead, I used this opportunity to push through an idea that had been bouncing around in my head since the year before: build a data-collection website that is designed to be finger-friendly so that teachers simply tap-tap-tap their feedback and let the database do the heavy lifting.

Selling the idea was not easy, as people "just wanted an Excel report", but I used a long weekend to prototype the site and build some dummy reports. I presented it to the managers the following week, and they loved it.

This was shortly after my employer had rolled out iPads to all of the schools in a bid to make us seem more efficient and professional. Both counts failed and the project was bleeding money but, again, I had enough hubris to think that I could push through my own agenda while using company resources to solve company problems. Within six months the project had expanded to include several different types of reports, and people were generally happy with the system. A few times the project came close to being shut down when certain members of IT learned of the project2, but there was always just enough pushback from the local schools to keep the project alive.

In 2015, after a redesign of the iPad software teachers were supposed to use in class, a number of people gave up trying to use the tablets in the classroom. We still had to use them to record attendance, lesson goals, homework, and other details, but a large portion of the teaching staff gave up trying to use the tablets beyond the bare minimum. The problem was that the software was poorly designed for the job it was hired to do. The textbook application was nothing more than a frustrating PDF reader that stuttered and crashed every 15 minutes. The pedagogical tool was sluggish, hard to look at, and buried all of the student profile information, making it very difficult to learn more about students — or record updates — before walking into a classroom. Despite transitioning from paper to digital two years beforehand, people were pining for the day when we'd drop the iPads and go back to paper records. The older textbooks that made use of cassette tapes were easier to use and less embarrassing than the iPad software.

So I decided to do something about it.

Again, over a long weekend, I mocked up a new pedagogical system that would work on the tablets while making the system easier to use for teachers and staff. Information would be easier to find and filter. Textbooks would be searchable and come with custom lesson plans to help inexperienced or fatigued teachers. Reports — my specialty — would be built in to the pedagogical system meaning that teachers would spend less time writing them while students and sponsors received more data from them. In the space of four days the demo was ready and I started to show it around to people at the day job.

People loved it. Managers loved it. Even some of the students commented and said that it looked simpler. HQ, however, wouldn't hear of it. There were processes and procedures and hierarchies to obey, and I was bucking the system. They demanded it be shut down, even though there was zero student information in the system. I "conveniently forgot" to do so.

Then, in the fall of 2015, an interesting thing happened. The president of the company caught wind of these projects I was working on and asked to see them. He then asked why I "was being wasted". A week later I was approached with the opportunity to transfer to do software development in the IT department and, in March 2016, it became official. That 4-day design of the pedagogical replacement system is still being worked on and refined today, and people are generally happy with it … except when they aren't.

Back to the Problem

Earlier I said that my problem boils down to a very fundamental issue that will never be resolved so long as I am working for someone else, and this is completely accurate. I have been working quite hard on the problem of creating effective software for use in education for almost five years, the first four years of which was in near isolation where I was able to design and implement features and functions as I saw fit. When I would watch people interact with my software, I would find problems. These were often actions they would do that I never once considered, and I would go back and find a better way to support their goals while also ensuring mine were met. People would come at me with ideas or complaints, and I'd listen and find ways to make the system better for them, again ensuring that my goals for the system were not lost along the way. The way I looked at the tool was very simple: the UI is for the teachers, the printed reports are for the students, the database is for me.

By doing this I was able to create something that teachers actually liked to use. Students were happy. I had a nice database full of numbers from which to quickly answer questions from managers.

Since moving into a role with IT this has changed. People at HQ are accustomed to working with software that fights you every step of the way. Want to record someone's attendance? You'd best have 3 minutes to spare, because what used to be a circle or an X on a piece of paper needs to be infinitely more complex in the name of "security". Want to know what textbook your student will be using after they finish their current book? Go ask one of the school's support staff, because the teaching software will not let you know that information without a fight. This is the state of corporate software in the world, and the previous solutions for the iPad and schools all came from this group of people. My software with it's opposite approach to the same problems is completely alien to the way they think about the job. This isn't a criticism or a disparagement. It's a fact. They're looking at problems as A⇢B⇢C⇢…⇢Z, and I'm looking at problems as A⇢F⇢Z.

It's no wonder there is a great deal more confusion at head office than at the schools. It's no wonder that when members of the various departments in Tokyo report "bugs" in my software, it's because they're not accustomed to software understanding a person's job and performing a bunch of steps transparently on their behalf. From a big picture point of view, I completely understand this. In the heat of the moment when I'm reading that email or new issue on GitHub that has nothing to do with an actual bug and everything to do with making the software harder to use, however …

Flip that Table!

I'm too close to the project. I've invested a great deal of time and effort into making something that is designed to be used by people who really couldn't care less what the corporate interests are. That's why I invested so much time into making the UI for the people who would actually use the software rather than the people making snap decisions months after the initial decisions had already been made. This is why I call people people instead of using the same language as other people in the corporate structure. The whole thing has been designed to serve the people at the bottom of the totem pole. HQ wants things changed to serve their interests3, and I am growing tired of pushing back.

There are, of course, a lot of people that I've worked with over the last year at HQ who do understand the goals of this project and have gone to bat on my behalf more times than I can count. A lot of very smart people with very sharp insights have helped take a rough idea hammered out in 4 days through to the state it's in today. Many of them are just as frustrated with the various emails, non-issues, and Friday 5:30pm deployment cancellation calls as I am. But there's not much that can be done to change this. The vision of the project is simply too foreign at the moment for people, and the sole developer is too angry all the time to cast it in a positive light. I really need to take a step back …

… and another step …

… and one more.

Because it really doesn't make much sense to continue dreading going into work. There is a lot of good about going in, too. I like a lot of my colleagues. I like the ridiculous amount of freedom I have within the organization. I like seeing people use my software without realizing they're doing more in 30 seconds today than they did in 5 minutes last year. It's a great feeling! I just need to stop being so attached to this specific project.


  1. This would be especially bad, given that I'm using my computers at the day job.

  2. these are the same people I work with now

  3. 15 months into the project, mind you …