Office-first startups with established high-performing engineering culture are great for jumpstarting engineering careers. Coast is one such startup, and this positioning is deliberate.
Rate of growth
I broadly define “career growth” as the accumulation of knowledge and experience over time. This includes an increased amount of scope and responsibilities. It is the main metric I use when thinking about career trajectories.
I always remind myself that I can learn pretty much in any role out there, but given how limited my professional lifespan is, I want to maximize the rate at which I learn (all other things being equal).
At its worst, you might end up with 10 years of experience that turn out to be 1 year repeated 10 times. This might be fine for some, but for me personally the aspects of growth defined above are more important.
Startups
Below are some of the reasons to consider a startup if you are in the early stages of your career.
Breadth and exposure
Startups build companies from the ground up. You get to learn and participate in many decisions made quickly across the whole company.
The breadth of things you will be exposed to allows you to learn not just all the tech that goes into building the product (from front-end to mobile, from infrastructure as code to distributed systems) but also all the other ingredients of building a company, from legal to marketing, from sales to customer success.
This breadth helps you understand what is that you want to do in the future, it helps you see how everything connects, and it puts you on the path to high-impact, large-scope roles in your later career.
Scope and impact
Next thing that the rate of growth unlocks for you is the increase of scope and resulting impact as the company grows.
You progress through the ranks faster – when you start, you pick up bugs and small stories, before you know it, you are designing larger features, introducing new infrastructure, and becoming responsible for big chunks of the system. You start leading others and define the direction of the product, the technology, and organization.
This growth of impact is unparalleled in companies that scale quickly. The same trajectory that takes months at a startup like Coast would take many years at a larger established company.
Joy and excitement
There is a lot of satisfaction in starting with the clean slate, with the latest and greatest, not encumbered by past decisions you cannot change and have to live with.
This joy of creation, fueled by quick turnaround times (days and weeks, not months and years), is the reason for so much excitement behind the startup life. The tangibility and immediacy of the impact matters.
The “halo” effect
Finally, I would argue that your choice of company is more important than your job title, your pay or your responsibilities. The resulting “halo” effect that comes from being associated with a successful company will open many doors in your future career. People would want to replicate that success that you are associated with by hiring you.
Conversely, the effect works the other way too – if you happened to step into money-burning, ponzi-scheme unicorn that fails loudly, you would have to work against the negative association even if you are a great engineer.
Of course, picking winners is hard, and you should look for indicators below that de-risk your decision.
Startup risks
Through the lens of jumpstarting your career, what are the things to pay attention to?
Maturity of engineering org
Are these brilliant high school drop-outs that surrounded themselves with equally inexperienced teammates? They might be successful in the end, but you all will be learning first-hand, making mistakes yourself where existing body of knowledge and experience could have steered you in the right direction much faster.
Path to profitability
Do you have clear unit economics, do you know how to make money and when are you going to break even? Are there real paying clients? How often do you sign new ones, what is the trend over time? Or are you searching for product-market fit, or, worse, thinking about mindshare first and monetization later? All of these might be valid approaches, but they increase your risk.
Vote of confidence
Who is backing the startup? If it is venture capital firms or individual investors, what is their track record? Recognizable names serve as votes of confidence. Of course, take it with the grain of salt, but consider it a signal.
Runway length
How much money does the startup have, how fast is it spending, and what is it planning to spend? Does it need to raise more money and when? How much more money does it need to raise?
Culture alignment
Does the energy of the company suit you? How about transparency, openness, and ability to listen? How hard do people work and what is being rewarded? How was your interview experience and how were the people you met? Have you talked to people at the startup with a similar background and career trajectory to yours?
Founders
In a small company, especially a startup, founders matter. They can make or break the company.
What is their track record, have they done this before, how reliable/respected/accomplished are they? None of it is an absolute requirement, but it helps you gauge your risk.
Career growth and office-first
Onboarding
All other things being equal, the rate of growth for the product engineers just starting out in their careers is much higher in an office-first, in-person environment.
To begin with, remote-first teams, especially in organizations that only transitioned to remote setup recently, often struggle to onboard their less experienced engineers effectively.
Communication and serendipity
The virtual channels available to us these days are so imperfect compared to high-bandwidth in-person communication. And these channels need to be established deliberately, which introduces even more friction.
When a company is learning to be remote-first, the old baggage of in-person experience for existing teams makes them struggle to find the new tools and use them effectively.
Now, compare this to the in-person teams when less experienced engineers were embedded in teams in the office, soaking up the knowledge and experience with the teammates around them; overhearing conversations and asking questions. This happened “naturally,” that is to say—with a lot less deliberate effort.
Relationships and trust
Have you ever worked with someone where you just seem to talk past each other and each conversation starts with a long process of getting on the same page? That usually is a symptom of a lack of trust. As humans we rely on high-bandwidth in-person communication that includes all the micro-signals to build relationships which also allows for trust to build quicker, which leads to more effective communication, quicker decision making, more gelled teams.
Consider Coast
I maintain that Coast addresses the existential startup risks above: we have a clear path to profitability, we are backed by top names in the VC industry, we have money in the bank and a long runway. Our founder has built a successful company before Coast.
When it comes to jumpstarting engineering careers, what sets Coast apart from many startups is the maturity of our engineering team. We are not figuring out how to write software for the first time in our lives—we’ve done this for a few decades, we have experienced both success and failure, and we have learned from them. You are stepping into a well-gelled team that is firing on all cylinders. Picking up a product engineering skillset here will jumpstart your career.
At Coast we doubled down on the benefits of office-first setup. We recently moved to our larger NoHo office, and the whole company is together—one gets to talk to sales, interact with marketing, overhear client support calls, and chat with our legal and HR on the way to the kitchen. Our founder and CEO still favors the office couch as the place to write emails.
And of course, we have the high-bandwidth product engineering team interactions—the quick chat & sketch by the whiteboard, the ability to pull up the chair and look at the code together, the ease of getting a quick acceptance criteria clarification from a product owner that sits a desk away, or the casual discussion of a far-fetched idea on a walk to a lunch spot a block away. These serendipitous ambient encounters add up.
Deliberate investment in growth
We do a few more things to set up our less experienced product engineering hires for success.
Optimizing for new hires becoming productive quickly:
- Reduce complexity – your productivity suffers each time you have to pick up a new language stack, or a new technology, or follow a maze of special cases. If there is a way to reduce cognitive load, to simplify, we go after it. It might actually require more effort to make things less complex, but we are dealing with the team multiplier over time which makes it worth it
- “Living” onboarding documentation – each new hire improves it and provides feedback
- A “buddy” for each new hire – “near cache” to answer questions, a single first point of contact to help with onboarding
- Emphasize consistency – ideally, there should be a single way to do something, and it should be easy to find
- Establish and document patterns – these are common ways of doing things that you can simply adopt and avoid the need to research and choose your own
- Push into the code our common approaches and patterns – this makes following them even easier
- Increase automation and tooling – is the next logical step. Once the patterns are known, they should become the building blocks that could be reused, thus reducing mistakes and cognitive load
Culture of peer review:
- Collective code ownership – we take it seriously and invest in reading each others’ code and in providing feedback. This is how we get better together
- Design document reviews – this is an earlier chance to engage with the designs before they end up as code. We learn how to explore the problem space together and establish the consistent approach to evaluating the solutions, including quality attributes
Pairing:
- Buddy – each non-trivial story gets one to establish a lightweight “pair” for design, implementation, testing
Teaching and mentorship:
- Dev talks
- Demos and tech spikes
- Once we grow more, our formal mentorship program will kick in
There are a lot more details and additional context in my “Timeline for a newly hired product engineer” post.
What are we looking for in less experienced product engineers?
I start with the foundation – a couple of years of professional experience in one language ecosystem (package management, toolchains, third-party libraries), working as a part of a team, deploying stuff to production, and running it for real clients.
If I were to advise a person either already with this background or just starting out, below are some of the things I would call out.
- Learn your first language and its ecosystem thoroughly – many of the concepts overlap, so investing in one foundation will make it easier to pick up others in future. Also you need to know how stuff works—abstractions always leak
- Cloud – most startups will be cloud-first. If you were to pick one cloud tech, pick AWS because of its market share. Focus on the stack most likely used for product engineering—serverless, a single persistent tech, and REST + messaging. These building blocks will be the foundation you will find in almost every startup
- Seek feedback – pair, get code reviews, even watch someone go through the code as they are explaining something to you
- Write – blog posts, design documents, even acceptance criteria for stories. This teaches you to organize concepts and articulate them. So much of the craft of software is the craft of communication
- Read code – this is a super-important part of working on a team and a different skill set from writing your own code. Contribute to Open Source projects, double-down on code reviews in your current team
- Teach as you learn – this is a chance to learn how to explain things, how to organize them in your head. After all, this is how you truly learn—you think you know something, but if you really want to know something, then you should teach it. Sign up to do a talk and use it as a forcing function to organize you. Learning in public is a great way to do it—it gives you courage, accountability, and motivation
- Find a mentor – easier said than done, but it is a relationship worth investing in
- Don’t work alone – it is OK for hobby projects, but product engineering is a team sport—learn to work on a team, ideally a cross-functional team that has product and design on it
- Learn your business – how does your company make money, where does it spend its money, how does it react to the economic changes in the world at large, etc. Talk to people outside of engineering, build relationships. It is an investment, but it puts your work in context and makes you a better engineer in the long run
