Six Steps for Succesfully Starting at a Startup

Landing a job in the modern day is only the initial problem. Quickly jumping onto the moving train that is a young, vibrant startup is a whole separate ordeal. Orientation is ever-maturing, documentation is ever-deprecating, and your team's efforts needs to be prioritized and balanced between bringing you up to speed and keeping the machinery running properly. In my few months at Cloudflare, I developed a few effective strategies to quickly acclimate, impact, and succeed at a startup.

1. Overdocument Everything

The Problem

Fast-moving and nimble companies are notoriously under-documented. The process, procedure and customer change too often to survive any semblance of knowledge management and version control. The person writing the material would be better off improving the product than detailing how it works. Small companies feel this resource gap even more directly, although even at Google, more inner workings are kept in the minds of the engineer than on paper where it can quickly grow stale.

I have a very good example from my twelve week internship at Google. While I was creating brand new documentation, I had to put the phrase "Deprecated Soon" on a few of my key slides explaining how the system worked as a whole. So, as I tried to help all those joining the team after me, I was still far behind the change curve to properly document the realities of the system.

The Solution

So, as someone recently joining a fast-moving company, you are very well-positioned to solve this problem. You sit outside of the day-to-day work load. Your daily task is to learn as quickly as possible, to understand the system as quickly as possible, and ideally, to help everyone that joins after you learn faster than you did. This puts you in the perfect spot to over-document everything.

Here at Cloudflare, I went back to basics, old school, word processing 101; I logged everything on pen and paper. This served a few goals. It allowed me to recall things in greater detail later. It allowed me to focus on the moment instead of my computer screen and latest email, and it gave me the ability to refine, consolidate and revisit later. I highly recommend pen and paper for your first few weeks.

I wrote down everything, and I do mean everything. I started with Week 1 on the top of a legal pad and went to work. Every person I met with, every orientation topic, and every buzzword and vocabulary lesson. Every client call I shadowed was listed with important details and questions. I listed Action Items (AI), Research Items (RI), key takeaways, sales factoids, and grand challenges along the left side. And, at the end of the week, I wrote down everything again.

On Friday evening as the work-day settled down, I went through all my notes and moved them to a digital copy. I consolidated, refined, and simplified my chicken scratch onto a full note for the week. This merging allowed me to revisit the notes, prioritize items, absorb the material again, and better track my learning. Consolidating these notes acted as a great bookend for the week, and allowed me to be better prepared for the next.

The Result

I kept this paper note taking strategy going for the first few months until it eventually faded away to a purely digital solution. I have paper copies of Week 1 through 15 all tucked away and vaguely organized. I have my digital version in place which is still going strong. Its cleaner, simplified, and most importantly, it is shared. All new hires can dig into my first few weeks here and understand key highlights, factoids, and WiFi passwords that may be important for them to know. Sharing and distilling is where this strategy really pays dividends.

Over-documentation in the first few weeks lends itself to being just the right amount of documentation at a fast-moving company. My notes have led directly to an improved onboarding experience for new Solutions Engineers. They have improved internal wiki pages, client-facing documentation, and our internal processes. And lastly, they helped me come up to speed quickly and find my footing at this fast moving company.

2. Lower the Volume

The Problem

Information is everywhere. You will be flooded with information about the company, the role, your benefits, your team, your customers, your product, and the latest company event. Some of it will be deprecated, some of it will be out-of-scope, some of will be vital. All of it may ultimately apply to you someday. However, today is not this day. Tomorrow is not that day. Next week is not looking good either. That is perfectly all right. Right now, most of the information is noise.

I am a big proponent of finding the signal from the noise. To determine your sphere of influence and ignore everything else until it enters that sphere and matters. It is simply noise until you fully understand it, or need to work with it. Lowering the volume on this buzz will help you keep focused and sane in your first few weeks. I've listed a few basic steps I took to keep the flow of information reasonable. As much as I highlight over-documenting everything, you still need to take steps to document the important things.

The Solution

Automated email seems to be a fact of modern business life these days. You'll get updates and tickets and announcements that need sorted, stored, and filtered. I tend to keep a clean inbox, and pushing daily notices into their own folder is a simple and effective tool for reducing the volume. I'm up to eight folders/labels to appropriately capture all the automatic stuff.

The meeting notes of product from three months ago may be fascinating. This information is likely great as you mature in your role, and it will help you better understand the questions that were asked during product development. However, this information likely isn't very vital for you in your first few weeks at a start up. When I started, I explored the wiki and any additional documentation sent me, but I kept things focused on my role and my team and didn't get lost in the noise from other departments.

I learned this lesson very acutely last summer. Early during my Google internship, I fell in love with the free flow of information after working in a need-to-know environment. I would listen to year old TGIF meetings to learn more about the direction and vision of the company. I would read up on random projects and wiki pages. It was like having an inside scoop on the future. The information was fascinating. It was intoxicating. Was it awesome? Yes. Did it help me in my day-to-day task? Not really. I leveraged this learning experience as I started here at CloudFlare.

The Result

My inbox in rather clean, organized, and always almost zero. I have even shared my filters for future generations to save themselves from the onslaught that is automated email. These can be updated or adjusted to fit individual needs, and they solve the volume problem for future employees.

As my sphere of influence and understanding grew, I found more value in revisiting historical and deprecated information. I had enough of a footing to absorb and take action on the information. This expanding sphere allowed me to revisit the noise and find out it had turned into wonderful, understandable signal. Understanding where a product came from is extremely helpful in understanding where it is going. You can easily find the questions that no one has asked yet and pursue those answers. However, that is best done once it can be turned into workable information.

3. Find the "Wish I Had Time" Project

<

The Problem

Everyone at a start up is busy keeping the lights on, the engine running, and everything afloat. (The mixed metaphor is perfectly valid.) This means improvements and fixes can take a back seat to everything else. Your team simply doesn't have the time or resources to dedicate to that little non-urgent solution that would pay huge dividends now and into the future. So, documentation goes unwritten, that code goes unscripted, and that process remains janky and broken.

The Solution

You.

Guess who has time to dedicate to all of those things? You do. Starting up at a start up, you have two main goals while you are ramping up. Learn as much as possible as quickly as possible, and improve anything you have the bandwidth to improve. Your day will soon be consumed flipping light switches, cranking engines, and plugging leaks. Until that day comes, you have the perfect opportunity to positively impact your team.

Want to find out what to do? Ask your boss or your team. I guarantee that there will be an idea or an improvement that would be wonderful if it was created and implemented. I have dubbed this the 'Wish I Had Time' Project. Ideally, you find something that stretches you a little bit. A project that is a little difficult, a little beyond your skillset, and outside your team. This will allow you to learn, develop and ask questions as you make an impact in your first few weeks.

Specifically, I applied this logic to a variety of tasks within my sphere of influence. I took over long-forgotten scripts that kept things running smoothly. I improved our documentation both internal and external, and improved customer experience along the way. These little projects filled my time as I continued to learn and develop in my role and take on more client work.

The Result

Finishing the 'Wish I Had Time' Project pays dividends to you, your team, and your learning. Typically, you get to interact with others outside of your team to accomplish the goal. This increases your sphere of influence and your knowledge base. You get to stretch yourself and learn new skills. And lastly, your team benefits immediately from your extra bandwidth as you ramp up.

In fact, we've had so much success with these projects that we have formalized them in our new hire onboarding. We call them "Pre-Client Projects". New Solutions Engineers can and do make an impact to our team almost immediately. Before their day-to-day work becomes a mixed metaphor, they create piece of awesome that someone wishes they had the time to do themselves.

4. Shadow Up and Down the Process

The Problem

As you are starting, it is very easy to get really involved in your specific role. Your training is very focused, your interactions may be limited. It only makes sense. You are ramping up to your specific task, and it is not immediately necessary for you to view the process at different levels. However, this hyper-focused approach can be very limiting to understanding the machinery fully.

The Solution

However, there is too much to gain from getting the perspective of those above and below you in the official/unofficial/non-existent process. You should spend time shadowing the people that support you, and you should also shadow those that you support. Talking with these two groups helps improve your understanding of the inputs and outputs required. By getting a greater picture of the way things currently work, you can expand your knowledge, company contacts, and sphere of knowledge and influence.

Specifically, I spent time shadowing our Customer Support team at CloudFlare. These were the guys that see the biggest problems of our customers day in and day out. And ultimately, these are the guys that clean up my mess. The worse I do at my job training and onboarding the customer, the more work I ultimately create for these guys. Shadowing the Support team helped me discover the most common problems of my customers and the most glaring weaknesses in the process within my own group.

The Result

In my case, I begin to take steps to improve the interactions between Sales and Support. I searched out ways to automate things and provide a smoother experience and interaction. I worked to improve customer education and training to reduce common issues. It aided me in empathizing with the entire support team. More generally, this shadowing can provide you with a better level of understanding where you fit in within the company and the connective tissue between groups. This should help you understand and view your job from multiple levels.

5. Exploit Your Newness.

Shoshin - a concept in Zen Buddhism meaning "beginner's mind". It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject.

The Problem

Similar to the logic behind the "Wish I Had Time" Project, employees within a startup can get a certain level of tunnel vision in keeping things running. They don't always have the time to step back and really get a look at their work from a different perspective, such as their customers. (And to be clear, customer doesn't have to be the end customer. Whoever the consumer of your work or process is your customer.) These myopic view points can lead to problems and increase process debt. They are already locked into a paradigm that works for them, but that may no longer be the optimum solution, if it ever was.

The Solution

Leverage your newness. Ask questions. Ask stupid questions. Ask why. You don't know how things work. You don't know how things don't work. You could be a light onto the old paradigm that highlights the crud, gunk, and broken windows that no one has tried to open in years. You can bring new eyes to the current solution and find the weaknesses and awkward steps that simply don't make sense anymore. Don't be afraid to surface these potential weaknesses.

The Result

Specifically, I took the perspective of a new customer. Of someone brand new to CloudFlare working through our onboarding process. Using this nativity, I was able to highlight weaknesses in the communications we use for our customers. We have used these new communications and structure consistently since I've pointed out the weaknesses. Using this perspective combined with my shadowing from Step 3, I was able to link this to weaknesses in our internal process and hand offs. Ultimately, my newness allowed me a way to really get a complete picture of our current customer experience.

More generally, asking stupid questions allows you to learn in greater detail. This leads to things getting better. The paradigm changes and improves. Your team runs more smoothly and more easily, and your newness is used for more than just awkward questions about where the bathroom is located. So, don't be afraid of being new and leverage it as long as you can.

6. Break Something (preferably not a customer).

The Problem

A startup doesn't always know what it can't handle. Things are changing very rapidly, technical debt is very common, and new challenges are constantly being introduced. All of these things introduce a certain level of fragility in the day-to-day interactions between internal groups and customers. This fragility can be very dangerous if discovered by the wrong person such as a customer.

The Solution

Break something. Find a fragility. Find a weakness. Make this weakness known and the costs involved for it to remain a weakness. Sometimes these frailties will be known, and the costs already considered. But, depending on how you discover the problem, it could be completely novel, completely risky and lead to a positive change. You'll never know until you actually try to discover the weakness.

As for me, you shouldn't worry. I did not break a customer. Specifically, I did something at new scale. Being a few weeks in, I did not know the "proper" way (i.e. the workaround). I attempted a handful of sanity checks by asking a few others. Apparently, I did not ask enough. I ended up breaking things out of sheer scale. This surfaced a technical fragility and a weakness in our internal process.

The Result

There were a handful of things that happened due to my breaking things. First, I added about five hours of work for our ops team to clean up my mess. Second, I immediately improved the documentation on the workaround for future sanity checks. Lastly, the internal process and communication between these groups is being actively improved. Ultimately, we learned something new as a company. We learned something that didn't work. We then made positive changes to improve the situation in the future.

As a new person in a company, do not be afraid to break stuff. If the system is so fragile that a new hire could cause a catastrophe than that system was too weak to continue as it was. It needed to be broken and fixed. That technical debt needed to be paid, and it was better that you caused the problem than a customer. In fact, if you haven't broken something early at a fast paced startup, you may not be trying hard enough.

---

Originally Posted Feb 13, 2015 SomethingSubtle.com
Hero Image - Bay Bridge Construction - San Francisco Public Library
Non-attributed images CC0 Public Domain

---

_{Career and Job-Seeking Posts
The Modern Headcount}
^{The Modern Job Hunt}

---

^{Follow Me|| Starting at a Startup || SomethingSubtle.com || New to Steem?}