An exciting part of company building is actually building the company! That is to say, building, from scratch, the organizational operating system that’ll power the way that you and your team works.

This is especially important as the organization grows because what worked in the beginning will definitely not work the moment everything starts to scale!

Gut instinct can sometimes have diminishing returns.

For instance, when @peter and I first started building things we didn’t need complex organizational tools or project / product management workflows – instead, we simply required the truly essential tools to get stuff done:

  1. Email
  2. iMessage (sms / text)
  3. Dropbox (both for files and for documents)
  4. GitHub

Between the two of us we had everything we needed! We could connect freely about our work and if we needed to send any files or screenshots we could use any of the above three (and they were used interchangeably).

The beauty here is that alignment was happening both in real-time and asynchronously, if anyone needed anything we knew where it was and where to find it. There was a lot of agency and freedom within our simple system.

And for a time, it was good.

But things can start to unravel and come apart as quickly as you’ve put them together, especially when your team and organization grows in size and number!

What worked once will no longer work and it’s time to intentionally sit the team down, review how things are actually getting done, and optimize, optimize, optimize!

And this is where the experiments begin.

Our Trello-powered Team Handbook

Try Not to Go Overboard (It’s Very Tempting)

When we first started thinking about codifying the way that we worked I threw everything and the kitchen sink into the mix, reviewing a ton of “Product and Project Management” tools, productivity suites, GTD workflows, and more, all of which didn’t actually help.

Instead, what I should have done is iterate and intentionally keep things as simple as possible. When the team went from 2 folks to 3 it can feel as if it’s a huge change (and it is, in many ways!) but that doesn’t mean that you have to rework all of the foundational systems from the ground-up.

In fact, our 3rd team member was able to easily adapt to what we had put together and she had the unique opportunity to speak into the existing process and ask us the tough questions of why certain things worked the way that they did and what our original intent and motive(s) were.

The point is that it’s entirely okay to go small with your tooling upgrades, experiment lightly with different implementations in your current systems and workflows, and then add-on as necessary.

Consequently, we’re using Trello, again, to build in a little more high-level alignment around our tasks, what we’re working on, and the larger goals of the team and organization by week and also by quarter.

It’s getting quite large.

Every week has a few “repeating” events and cards while everything else is related to that specific week. And as each week finishes we just move them farther to the right as Archived Weeks. We don’t use any complex logic and we leverage most of the out-of-the-box features of Trello, including:

  1. Members
  2. Labels
  3. Checklists
  4. Due Dates

Here’s a good example of a card that uses most of these things: My Monthly One-on-One Meetings with each of my team:

I enjoy these immensely!

Finally, some of these cards do roll-up into larger Quarterly Goals and if they don’t fit anywhere specific, we’ll put them in an Icebox for future review:

It works. Not perfectly, but, it works.

Now, is this Kanban-esque workflow working for us as a team? For now, it is, but it is definitely not perfect and there are a ton of gaps and even long-standing frustrations with this system and it’s very possible that we’ll scrap this particular experiment and implementation for more advanced tools.

Don’t forget that the temptation to over-optimize will be incredibly strong – and, it can be just as bad (if not worse) then not reviewing your internal systems at all!

Organizational Change Doesn’t Happen Overnight (Nor Should It)

The biggest lesson that I’ve learned this time around while updating and upgrading our internal processes is that I’ve learned to embrace the tension (and frustration) of how much time is required for real, fundamental, organizational change.

You see, once the team and the project really start gaining steam (traction, users, visits to the site, customers, sales, etc.) the number of interdependencies begin to grow exponentially.

In fact, you may not even fully be aware or know how many interdependencies exist in most (if not all) of your systems today! For instance, if I were to make an executive decision and turn off Trello for our entire team, it would have immediate, negative impact on how we operate!

With a team of two (like it was when we first started) the collateral damage of a decision like this is relatively small; it can be quickly fixed or adjusted. But this is no longer my current reality and, consequently, I can’t simply “pull the plug” without first spending time understanding what the real, downstream impact is going to be.

The rule of thumb is this: As a startup scales (grows bigger and older and hopefully more wiser) the systems within become even more critical to the startup’s success and the evolution of those changes have even bigger impact (which could be both positive or negative).

Here’s a quick, hand-made graph that I created as I thought on my previous experiences building early-stage companies:

Everything starts in my personal notebook.

Those “squiggly” lines represent moments of crisis or a major evolution within the business, which could be a number of different types of “events” that any early-stage startup could experience.

Here are three, more obvious examples:

  1. New hires and team members: Adding anyone to the system is going to fundamentally change the system (as well as removing them). The earlier in the startup’s life the bigger the impact. Choose wisely who you hire to maximize alignment!
  2. Raising venture capital: Some startups will bootstrap while others may decide to underwrite the costs, so to speak, by offering equity in the company for financial support. Although the influx of capital isn’t so much of an “event” in and of itself, the outcauses of having more money in the bank are definite evolutionary changes, the most obvious one is the ability to now hire more folks, faster.
  3. Major product update: Software-centric startups are always trying to minimize their “cycle time” between building new (planned) features, fixing identified bugs, and responding to customer requests.

Every release, especially in the beginning, can be interpreted as a significant event in the company’s life! And, these are critical and opportune moments to review existing workflows and optimize them, especially when the event is fresh in everyone’s mind.

But don’t miss the larger perspective: Real, functional, organizational alignment takes a ton of intentionality by the founding team and is much, much easier to say than to execute against.

Ron’s had enough.

And, because real organizational change is principally based on human capital (i.e. your staff!), we know that people (just like you and me) do not change overnight and, as a consequence, the organization (and its implicit and explicit systems) won’t either.

This is why you, as a startup team and most certainly as a founder, cannot get overly-frustrated or upset by the pace at which you’re evolving! You’ll have to iterate and experiment your way there, making the small, intentional, and iterative improvements as you fight for organizational alignment.

And, of course, remember that the “go nuclear” option is no longer an option when there’s more than just you on the team (although I will admit that I still wish I had one)!

So take your time and remember that the compounding interest of your team’s repeat deposits of time and investment in the areas of organizational alignment and tool choice can, quite literally, make or break your startup!

Either you’ll optimize by choice (i.e. do it collectively and with intention) or you’ll be hoping on a prayer that somehow, magically, your team will somehow organically develop alignment even while the organization is continuing to become more and more complex – good luck with that!

We’re Not Even Close to Being Done

Now, with all of this being shared, you might mistakenly believe that Trello has found a near-permanent place in our hearts as we continue to build our products and company!

#ThisIsUs

But, you’d be wrong.

There are a dozen things that either annoy me superficially or that I simply can’t do with this slightly-more-advanced workflow system that is Trello. Yet, that’s entirely fine and I’m okay to live with the frustration because I understand the iterative and evolutionary process of a team and its systems.

Trello is a huge update to the system that my cofounder and I first instituted! And, it is certainly not the last one that we’ll deploy and use.

Rather, it is the next logical and iterative step for our growing team. It is also a conservative upgrade which can be applied liberally throughout our other business systems without slowing them down or negatively impacting throughput and productivity.

In the months to come, we’ll continue to refine and experiment with our Trello-based workflows and when the next major event appears, we’ll be ready to assess its efficacy and have the muscle memory, as a team and culture, to make even better and more informed workflow decisions.

And so should you.