Year 1: How We've Failed So Far

About a week and a half ago, we celebrated the one year anniversary of Transeo (based on our first GitHub commit).

This week, our partner schools will begin to introduce their students to the platform and start flooding the system with data.

For context, Transeo is a cloud-based tool that allows students and school administrators to track, analyze, and celebrate community service hours more efficiently. We make it easy for all parties to recognize achievements and identify metric-based paths forward.

Too often I see articles celebrating massive success, another funding round, or an acquisition — those articles are great, and the team has definitely earned that right. Frankly, though, too few people discuss the failures that occurred along the way, which is a significant disservice to the future of the team, as well as other teams trying to get off the ground. I’d like to share three impactful organizational and operational failures that we faced in our first year, and the lessons we took from them to make sure they don’t happen again in year 2.

Failure 1: Empowering processes instead of people

Early on, I made an effort to implement as many procedures as possible. We’re a remote team, and a good portion of our team is part-time. This makes for an interesting communication challenge on a lot of different fronts, so my attempt to solve that problem was to put structures and a semblance of order in place.

Idealistically, this is a good start. There theoretically should be some form of a company-wide structure when it comes to action items like reporting weekly progress, sharing challenges, and asking for help.

Realistically, however, this didn’t work out so well. One of the processes I attempted to implement early on was a streamlined communication channel. Up to that point, our communication was done solely via email with threads strewn everywhere and no proper way to organize information. Naturally, as someone who has worked in tech before, I tried to implement Slack. Big mistake. Our team was mostly sharing long-form text — paragraphs justifying decisions and proposing new ideas rather than communicating in real time. In hindsight, we would have been 100% better off with something like Basecamp.

There were a few things wrong with this decision, but by far the biggest one is that I didn’t do a good job listening to and understanding the team’s needs. I rushed to a conclusion based on historical context, instead of present-day evidence and forced an organizational process that just didn’t work. As a result, I had chosen to empower a meaningless, ineffective structural change instead of the people building the company.

In the future, we’re going to drive processes that make sense contextually — procedures should not force people into changing a routine or structure that has been proven to work. This doesn’t mean that all processes are wrong — there are indeed situations that necessitate structure and change. That being said, one of my goals going into year 2 is to make sure that I evaluate and propose changes based on where we are and where we need to go, not just my past experience.

Failure 2: Sticking with our assumptions instead of challenging them

This failure has more to do with the technical side of the company rather than the operational team, but the lessons permeate across all departments.

As we began building out the product, one of the immense technical challenges we faced was figuring out how to get initial student data (names, emails, student id numbers, etc.) into the system. Luckily, this is a problem that has been solved many times before, so we looked to the past for inspiration. Big mistake.

For those who don’t have experience with the Ed-Tech industry or don’t know how software works in school districts, almost everything is ridiculously archaic. This isn’t the fault of the schools, but rather the breakdown of the entire industry for failing to push better standards forward (There are companies trying to fix this, like Clever, but the vast majority of schools districts are still based around the old standards).

For example, schools expect platforms to be able to support CSV student upload files — we knew that from the beginning, and that’s fine. We assumed that as long as we provided a form for schools to upload their user CSV files, we’d be good to go. Wrong — schools want the ability to run that process from a district level.

Totally understandable, so we built a district-level dashboard that allows district tech administrators to make sweeping changes to all of the schools under one umbrella. That wasn’t it though — most schools want to automate the process by connecting it to their SIS (student information system) so that they can upload users nightly. We had to build a custom SFTP server to do that.

For those following along at home — yes, most of our schools are seeding their Transeo database via automated, nightly CSV files uploaded through SFTP.

Honestly, that’s perfectly ok. We recognize that we’re not going to be able to change the technology standards in the industry, so at this point in time, we have to conform to them. The failure in this situation is that I didn’t realize it from the beginning. It’s my responsibility as the CTO to ensure that we challenge our assumptions about how our technology should work in a school setting — and I failed to do that. As a result, it added extra development work on an already tight schedule.

This is just one example of this failure — as a tech team, we failed to challenge our assumptions on so many different features. Honestly, though, I think that we have a better product because of it. The initial feedback we got on our early version 1 platform drove forward what we chose to work on after that.

I don’t know where we would be if we had aligned our expectations correctly from the beginning, but I do know going forward, our product and company decisions are going to be rooted in asking if the underlying assumption is correct.

Failure 3: Not setting team-wide expectations from the beginning

This one is pretty large — from the beginning, we didn’t have defined expectations of who should be doing what. Big mistake. When I look back on this, though, it’s not surprising. As we were getting off the ground, all we cared about was making sure that marketing, design, development, and operations knew how to exist, we weren’t thinking about the best way for that to happen. As a result, we often had moments where we didn’t know who was supposed to cover an action item and if they had done it. This struggle strained our productivity and even shut down a few potential opportunities.

On top of that, this failure often manifested in the exact opposite way. Because the majority of the team didn’t have rock solid job descriptions or expectations of day-to-day work, action items often crossed into other member’s arena, causing undue tension because there was no clarity around who was supposed to handle it. Theoretically, each member of the team should be free to contribute to any other department in the company to maximize the efficiency, but this only works if people know what the departments are.

We’re in the process of implementing new company-wide practices to fix this issue, but it’s undoubtedly something that would have been better if we had caught it earlier. And here’s the thing — I’m ok with that. I’m ok with acknowledging that this was a misstep. The question now becomes how we’re going to grow from there.

What’s Next?

We’re really excited for the future — between our first batch of partner schools and on-boarding a ton more for next year, we have our hands full with what comes next for us. My biggest personal goal going into year 2 at Transeo is to continually evaluate where we are, and how we can get to where we need to be. These failures have been the most valuable learning experience in the company, but we’re not going to stop — I’m ready to see how we will fail this year.

Tagged with: