Coming from a major tech company to a startup?
It's a bold career move, and a courageous adventure. However, be prepared, here is what you must know to succeed.
This is the most important thing for a startup. Startups either deliver or they die, loosing in competition, so your first and primary objective is:
- Get your shit done.
- Let other people get their shit done, by avoiding disrupting / public idle talks / paradigm shifts / challenges of status quo / solving non-existing problems.
Deliver like crazy, deliver like there is no tomorrow. It would be nice, if by the end of the probation your colleagues say: "This guy was so busy delivering, that this was the first time we could take a photo of him."
Many startups don't have established processes, and they don't probably need them... for now. Scrum, planning, retros - forget about it. Most recently established teams use Kanban, and this is the way for them to go.
What it means for you is that after many years of Scrum in a big company, switching over to Kanban can be mentally confusing, so make sure you keep yourself on track, always. Set your own deadlines, try to pace with the team.
Your task is to prove yourself as a valuable contributor. If you are stuck with a huge task since day 1, and not showing any progress, you will be perceived as a burden.
Even if you somehow manage to deliver the result, there won't be people standing by your side and supporting you.
Instead, to make an impression, focus on 3-5 small "good first tasks/issues" and only then get a bigger fish to fry. This will also give you an opportunity to learn the product meanwhile.
After many years in a big company, where you were one of the respected and well-known engineers, it's easy to forget, that in a new place you are still a newbie with zero reputation. That is why you must be humble. You need to earn people's trust, and you need to be hungry to learn.
Looking into the codebase refrain from judging/criticizing/ironizing. You don't know the circumstances under which this particular, allegendly doubtful code was written, so you, sort of, don't have the rights to speak against it.
Giving up on judging will ease the pain of transition, and will eventually play into your advantage.
If you text something, before sending, take a moment and think: "Does the message communcate humility and hunger to learn?" If not, probably you should rephrase it or even refrain from sending.
It would be much better to shrug off the previous experience and focus on learning and contributing, being an empty cup, and then one day you will be able to speak your mind and propose changes.
In a startup the hierarchy is almost always flat, so there is something you should be aware of.
With the flat structure in place you'll be reporting to a CEO/CTO directly. They say CEO and CTO are very approachable, but… sometimes it can also be a good cover-up for micromanagement.
People could be terrified with a prospect of a CEO/CTO coming and reading what people wrote in Slack, so the comm hygiene becomes essential. Keep in mind, that the flat structure usually works one way, because whatever you say can be force-overridden by the chief, and you can't do damn about it.
Furthermore, you will most likely end up having an unpleasant conversation during 1-1 with your Engineering Manager.
So make sure what you write in Slack is not only correct, but also respectful, humble and brings some value to the table.
This is especially important for a remote-first environment. If people don't know you personally, you will only be seen as a face behind the messages in Slack. And messages in Slack... well, they are prone to misinterpretation and biasing.
So, don't stay silent. Make sure to participate in bonding rituals: "get to know each other" meetings, pairing sessions, weekly hangouts. If you are an introvert, it's even more important to do so.
This is a very important skill. Upon joining a startup, you will soon discover there is perhaps little to none documentation. It can be seen in a lot of companies with a low bus factor, where the code itself and the people become The Documentation. If the codebase is intricate, and you catch yourself running in circles trying to figure how the task must be done, this is the time to ask for help.
What you can do:
- First and foremost, admit to yourself you are stuck. Some newly joined enigneers fight till the bitter end, loosing time, energy and, essentially, credibility.
- Reach out to your onboarding buddy and ask to pair.
- Propose conducting knowledge sharing sessions on poorly documented parts of the codebase, taking mandatory recording and notes. Store the sessions in a shared place, so every new joiner can benefit from them later.
- Slowly build your own documentation, by writing down what you learned so far. You can present it when the time is right.
This is very important for a remote-first environment, and especiialy when the dailies don't happen frequently. To let the stakeholders keep a hand on the pulse of your work, feel free to drop short regular updates in Slack. Think of it as a way to present telemetry of your progress to provide visibility.
To alleviate the communication tension it's always a good idea to give up on the glossary of the previous company and learn the new one. Instead of saying "drawer", say "overlay". Used to say "design wireframe"? Say "design mock". Let people understand you better by speaking their language.
Honestly, how many times have you faced a non working "something" and thinking "What a piece of junk"? Well, the practice shows that most likely it doesn't work because you don't know the project and it's intricacies well enough.
Don't jump into conclusions and quckly seek assistance, instead of suffering silently.
Onboarding is... essential. Troubled onboarding will set you up for failure, so it's crucial to make sure it works. After the probation passes it's equator line, it will be also for your onboarding buddy to decide if you are a good fit for the team.
Here are the signs of the onboarding going pear-shaped:
- There is no chemistry between you and your buddy, and you avoid each other. Without the chemistry everything is falling apart, even if you have good relationship with some other people in the company: it's simply not up to them to decide if you stay.
- There is no frequent communication between you and your buddy, no pairing sessions, no hangouts.
- Your buddy replies "I am busy." or "I don't know how to do it, ask someone else." to your messages.
- If your buddy says "No, I am good." to your offer to help.
It's a touchy and tricky situation, you should discuss it with your manager as soon as possible, but do it in a respectful way. Maybe there is still time to fix it.
When you work for a company for quite a while, you know your mates as they are, so you can be more casual in your PRs. You basically trust them they know what they are doing, and they know you good enough to review your code without too much context.
However, on a new place you are still a newbie, so you need to be more formal.
In order to make a good impression, follow this PR framework:
- The work in progress PR must be marked as a Draft.
- Make sure the PR description is in place, and the title is descriptive, understandable and concise.
- Make sure the code works as required, it's okay to have the draft version WET.
- DRY the code to a reasonable extent, but don't overdo it. No need to do deep refactoring or couple totally unrelated things though shared code.
- Make sure the tests are in place, and the checks are green.
- Do the PR review once by yourself, fix spotted problems.
- Only request a review when the PR is in a good shape.
- Never merge the PR until all comments are addressed one way or another.
Be a good team player, and you will be treated as one.
During probation it's a good idea to have more frequent feedback sessions, ideally bi-weekly. This will help you to stay on track, and to make sure you are on the right path and meeting the expectations. This is also a good opportunity to do corrections early, before the situation is out of hand.
Do you have any other tips for people coming from a major tech company to a startup? Text me a message on LinkedIn.
