Lessons from a Startup Pt. II
Capturing more lessons from my time at an early-stage startup
In Part I of this series, I shared some of the “hardest hitting” lessons I learned as the first technical hire at EQ Community. If you missed out here is a quick recap:
- Writing Code is Overpowered — A small piece of code can generate a lot of business impact.
- Don’t Outsource your Code — Your code is a valuable asset and should be treated as such by someone committed to the company.
- Completion vs. Correctness — Figure out when to get things done vs done well, ideally you want both, but done well over done as much as possible.
- Failure is the Only Guarantee — You’re going to fail at something, accept it.
- Excitement can be Dangerous, Use a Fundamental Compass — Getting excited can distract you from what is important.
- Data is Useless — Data isn’t useful until it generates an action.
In this follow-up article, I want to continue to draw upon my experiences and preserve those lessons into something that I can always look back on for future reference.
Build out Workflow Playbooks
Do stuff, then think about the stuff, then figure out how to turn that stuff into a repeatable documented workflow. Most of our daily routine involves repetitive tasks like brushing our teeth or tying our shoes, and businesses are no exception. A documented workflow ensures that anyone can execute the process correctly. Additionally, documenting the workflow uncovers parts of the process that might be taken for granted and done on autopilot, opening the door for automation to step in. By following a workflow, team members are freed from having to remember the steps and can focus on more important tasks.
Journal from the Job — Every week I received excel data from our platform to my email and it was my job to transfer the data into our database and then move it to our S3 bucket. To make the process more efficient, I decided to write a step-by-step playbook covering everything from renaming the file, converting the file format, merging the new data with the old data, and even data disposal. Once the playbook was in place, all I had to do was run it every week when the new data arrived. With the documented workflow complete, I realized that the entire process could be automated by using code triggered by the upload of the raw file to S3.
Red Tape is Inevitable
When we first started out, we had complete freedom to do all the “stuff” we wanted, which was both a blessing and a curse (Excitement can be Dangerous). We were able to move quickly and act on our instincts. However, as we built out our technology and started generating more business impact, that freedom began to evaporate. We had to establish procedures and adhere to technical red tape to ensure consistency and stability in our systems. I’ve come to realize that that’s a natural progression for any company as it grows and matures.
As a startup, balancing freedom and structure is crucial. While there needs to be freedom in thought, discussions, and development, it’s important to have structure in processes to scale efficiently. Automation plays a big part in achieving this, and it relies on having a foundation of structure and standardization. This is why LinkedIn can seamlessly convert your profile into a resume — they convert it the same way for everyone.
Building is Easy, Maintenance is Hard
Innovation and experimentation are key to building something new, but ensuring its stability and functionality is a completely different challenge. As the system expands, the list of maintenance tasks becomes more complex and lengthier, including addressing technical debt, fixing bugs, adapting to changes, and integrating new systems. Maintaining a system can often be a greater challenge than building it initially, the requirements and expectations for stability and reliability increase as the system grows — making it a bigger challenge than the building part ever was… also known as Red Tape.
Scaling is a Different Beast
Building from scratch and scaling are two completely separate beasts. The impact that seemingly small modifications can have on massive systems is unparalleled. Consider the fact that streamlining a task by just one second, if it needs to be done a million times, would result in a savings of 11 days. On the flip side, taking one second longer adds 11 days.
Scaling a system can be a more challenging task compared to building it from scratch. Scaling an existing system requires modification to handle increased demand or capacity, which can bring new complexities and dependencies that were not present in the original design. These complexities may range from data inconsistency to maintaining backward compatibility, among others. Moreover, as a system grows and becomes more complex, it becomes more difficult to make changes without disrupting the existing system.
Conversely, building a system from scratch offers the freedom to design a scalable system without the constraints and limitations of an existing system… also known as Red Tape.
Journal from the Job — After carefully mapping out our data processing plan and testing it for several weeks, we were ready to increase the volume of data flowing through it. Our pipeline utilized concurrent record processing through the use of Lambda Functions. However, as we increased the data flow, we encountered an authentication concurrency limit on an external SaaS API. This obstacle forced me to think creatively and adapt quickly, which ultimately led to a significant code overhaul that allowed us to overcome the challenge. Looking back, I recognize the importance of being flexible and adaptable in the face of unexpected obstacles, as well as the value of continuously evaluating and improving our processes to ensure their long-term sustainability.
Picking the Right Tools
It’s crucial to choose the right tools for your organization. Whether a tool comes with a licensing fee or not, every addition has its own associated costs, including implementation, training, and maintenance. Each tool in your “stack” requires a designated person to oversee and manage it; without proper management, things will descend into chaos, especially if different individuals interpret the tool’s use differently.
Additionally, the cost of training new employees on a tool is often underestimated. While you may be able to master a tool quickly, teaching someone else to use it effectively is a different matter entirely. Without a manager to oversee the process, things can quickly spiral out of control. It’s important to account for these costs and allocate resources accordingly to ensure smooth operations.
Above all things previously stated, picking the right tools is important because trying to change it is extremely difficult. Once everyone has become accustomed to and adopted a particular tool, changing it not only requires retraining people, but it also involves altering their behavior and mindset to embrace the change. Changing those two things, in any area of life, is a high implementation cost.
Journal from the Job — After the first 12 months our documentation was scattered and disorganized, with documents spread out across various platforms and tools: individual notepads, emails, G-Drive, SaaS tools, etc. It was clear that we needed a centralized hub to store all of our important information.
I remember scouring the internet for the “right” tool and feeling a sense of relief when I finally found one that seemed to fit the bill. Convincing the team to adopt it was a challenge, but eventually I was able to get everyone on board and start using it to our advantage.
However, as time went on, I began to realize that the tool we were using wasn’t as effective as I had initially thought. There was a better option available, one that would make our lives even easier and more streamlined. The problem was, trying to convince everyone to make the switch was like pulling teeth. I found myself frustrated and disappointed, wondering why people couldn’t see the benefits of the new tool like I could. Looking back on it now, I realize that change is hard and people can be resistant to it, even when it’s for the greater good.
Questions I Would Now Ask When Evaluating a Tool:
- Does the tool complement the existing tech stack and streamline your workflow?
- What are the costs involved, including licensing fees, implementation and customization costs, training and onboarding expenses, and ongoing maintenance and support?
- Is the tool scalable, you need a tool that can grow with you?
- Is there a lot of customer support and resources available for the tool to ensure that you can get the help you need if any issues arise?
Documentation is King…Seriously
If it’s not yet clear where I stand on the importance of documentation, let me clarify it now.
Documentation is one of the most beneficial things that you need to be doing. Having solid internal documentation is the ounce of prevention that beats the pound of cure.
I acknowledge that, like all the other most beneficial things in life (eating right, waking up early, staying focused, etc.) it is an absolute hassle to develop and maintain —but the benefits are well worth the effort.
Setting up an internal knowledge management system enables an organization to capture and preserve the knowledge, experiences, expertise, lessons learned, and mistakes made, of all its employees, past and present. This body of knowledge can then be streamlined and shared throughout the company in a centralized location, ensuring everyone has access to the same accurate information when they need it. This knowledge hub could ultimately save the company significant amounts of time and reduce the risk of misunderstandings and errors.
It’s important to understand the level of difficulty to “catch up” on documentation increases exponentially. The quicker you implement proper documentation the better.
A3I Written (Accelerated & Augmented w/ Artificial Intelligence)
