I am often asked what the life of a newly hired Coast product engineer looks like. Instead of crafting an answer every time, I am following one of our engineering principles of writing things down for long-term scalability.
A lot of us at Coast have worked as consultants at some point in our careers. For a consultant the ability to show value from day one is paramount. We follow the same principles at Coast—as a new joiner you should be able to come up to speed quickly and see your work in production within days. This serves the purpose of energizing you with early success and focusing you on customer value.
How do we make it happen? After all, we are a sophisticated business with a deep technology footprint. Surely, onboarding could take months, as it does in large companies.
New joiner’s productivity within days is not an accident. Some of it is a function of our intentional reliance on commodity tooling, whether it is the cloud and its managed services, or popular languages stack. Some of it is investing in the automation and onboarding process. Some of it is simply writing things down and staying disciplined when it comes to maintaining this knowledge.
We focus a new engineering hire on a few outcomes over time. It is easy to get distracted when you are new, so a single goal to guide you for the first few weeks is useful.
Day 1: Get local end-to-end test suite running and passing
You can spin up and test all of Coast in your own ephemeral (local) environment.
This is a good outcome metric for our onboarding process—everything from getting into the office, to ensuring that the physical hardware works and connects to all the resources, to accounts and permissions in various systems.
And of course all the dev stuff—the toolchain, the dependencies, the infrastructure, the documentation.
We are improving it with every new hire, but the best result so far has been running everything on Day 2. It remains a good stretch goal and a litmus test for the state of our development ecosystem.
When you start, you get an onboarding buddy—a fellow engineer that acts as a “near cache” for all your questions. Only “cache misses” go to #dev on Slack.
We work out of our new NoHo office in NYC, so a buddy will usually sit within an earshot from you.
Week 1: Merge your first reviewed Pull Request into “main”
This is a good lens through which we can explore our development process.
Quality is an important metric to us—we are not slinging code together just to push things out as fast as possible before moving on to the next thing. First and foremost, we are building a sustainable business for the long run. This is a marathon, not a sprint. The core engineering team has decades of experience building software, and we know how low quality upfront grinds velocity down as the time passes and the team grows.
Despite being a startup, we know quite well what our business vertical needs, so we can confidently move forward with building for a long haul; there is no need to perform a myriad of experiments that by definition would be short-lived.
Peer review is one of the most effective tools that improves quality early on. Business software is a team sport—we capitalize on the benefits that collective code ownership brings. One can argue that reading code effectively is actually harder than writing code. At the very least, it is a different skillset. We acknowledge its importance and this is the capability that we invest in and develop as a team.
We insist on reviews from the very beginning of the story—one gets a “buddy” for the story—another engineer on the team—to design the story with; a second pair of eyes to provide feedback and bounce ideas off. If the story is involved enough, we write a design document which serves as a record of decisions made, their context, and a tool for deeper exploration of the design. As a new hire, your first story would not require a design document.
Regular planning process is something you will participate in with the rest of the team within a week or two of joining. This is where we talk through the batch of stories and collectively agree on their sizing and implementation approach. This batch defines the team’s focus for the next two weeks. This allows the team to stay “in the zone” and avoid scope changes and other distractions that impact velocity.
A “sliver” of value is how we write our stories. This way a story defines a client-facing, meaningful increment of functionality. We avoid partitioning stories by technology tiers. It might seem obvious to many, but it takes years of practice to develop the muscle to partition the features in such a way. It also helps to have the underlying software and org structure that make it possible.
Product Owner will help you decide which story to pick up (once you are up to speed, you would simply pick up the next available top priority story, thus avoiding any scheduling bottlenecks). Together with the Product Owner you will walk through the acceptance criteria as well as the testing approach.
Pull Requests (PRs) is how the story gradually gets implemented. We do our best to avoid large batches in our development process. This includes reviewing and merging a large amount of code. Each story becomes a number of small Pull Requests (PRs) that, upon merging, gradually “evolve” main towards the story completion. Your “buddy” continues to be someone you can bounce ideas off, thus becoming another half of a “pair” that also gets to learn the codebase. Each PR gets reviewed by at least one other person, and usually more. This is a chance to weigh in on the implementation and ensure consistency, correctness, and uphold a bar for quality. We hold each other accountable to turn the reviews around quickly and not let them linger. And of course we remain civil in our reviews—empathy, humility, quest for excellence, openness, lack of ego, trust, and curiosity are foundational.
The fact that your PR has been merged into main implies that you worked with the “buddy” to design it and implement it, your PR passed the review (that usually would result in a bunch of changes and some discussion), the PR passed all the existing test suites, got merged cleanly, and got deployed to the lower environment. Each merged PR will go to production, so it needs to compose correctly with the rest of the codebase. As PRs accumulate for your story, you will end up implementing all the functionality to satisfy all the acceptance criteria, as well as unit, component, and end to end tests.
This way you end up touching the whole tech stack as well as the whole development process. And this is just your first week!
Month 1: Take a full story end to end to production
Story in production is not just implementation, all the way from initial planning, but also living with it as real clients use it. You established and improved observability, you put in place usage metrics and integrated business metrics into various Slack channels, you learned the ebbs and flows of usage throughout the day and the week. This means you lived through the whole development life cycle described above at least once.
On-call rotation is the next logical step. We firmly believe that supporting your own work leads to incremental improvements that reduce the toil over time. There are no hand-offs to some other support team—we follow the “you build it, you run it” principle.
Of course, we invest in the underlying platform so that ownership is reduced to only the things you care about, the rest is taken care of by the underlying infrastructure. This is an ongoing process of identifying common things that could be pushed down into the platform to maximize product engineering velocity.
Site Reliability Engineering (SRE) is a big aspect of engineering body of knowledge. We are its diligent students, but we pick and choose what is applicable to us at the current stage of our company. For instance, we do not have a formal Definition of Production Readiness (DPR), but we do insist on documentation, observability, testability and a bunch of other quality attributes before launching anything architecturally significant.
Regular 1x1s with your manager are in place and is a topic of a whole difference post.
A cadence of regular team activities—dev talks, team meetings, retroes, all-hands—allow us to step back from the focus on just feature delivery reflect, adjust, learn, and have fun together.
Quarter 1: To infinity and beyond!
I am putting this time period here somewhat in jest—after all, Coast is a startup—we are nimble, we respond to clients’ feedback, we move quickly. We do have a product and technology roadmap in place, but its prioritization is fluid, and we have our ear to the ground, ready to adjust. Therefore, the cone of uncertainty widens rapidly as the time horizon exceeds a few months.
Planning is everything, while plans are nothing—when it comes to technology and product engineering we are not “agiling” ourselves into the corner, refusing to think ahead in the name of process dogma (or sheer laziness). We do plan ahead all the while embracing the uncertainty. Plans provide the mental model within which we can adjust quickly when the world changes.
Lightweight planning tools we use start with a year-long product roadmap that gets progressively refined as it gets closer to current quarter. We have quarterly OKRs that help us focus, we have two week sprints that reduce churn and distraction, we have week-over-week KPIs for each department that help us spot trends and impact the long-term outcomes.
By the end of your first quarter, you have participated in all of the above. Your work now lives in a larger company context. We expect product engineers to be aware of it and make decisions accordingly. As the saying goes, when designing a building—design for a city block; when designing a city block—design for a city.
Engineering hiring and recruiting also became a part of your job—you shadowed existing interviewers and then started on your own, averaging two interviews a week. We are growing, so attracting, evaluating, and hiring excellent engineers that we all want to work with is a part of the engineering job at Coast.
Personal goal setting started with your manager, establishing performance and development checkpoints you both agree on and track to.
Wearing multiple hats is what makes startup life so exciting and challenging. We expect you to have contributed in many other ways, big or small—recorded a company support phone greeting, contributed to our open source projects, configured our fancy office coffee machine, or took on some other internal process or tech improvement initiative that aligns with your passions outside of immediate day to day feature work.
Always evolving
We pride ourselves in taking the time to reflect and improve—continuously. As the company evolves, as the engineering org grows, the things that worked in the beginning might no longer work so well.
The process that I described above works now, but none of it is set in stone. I fully expect us to evolve it. The key is to train ourselves to reflect, to debate, to remain open to change. After all this is what makes the journey exciting, and in the small company your contribution will carry a lot of weight.
Apply in minutes