Our responsibilities don’t begin with a ticket or end with a deploy - our ideal team member is someone who identifies what we should work on, figures out how best to tackle it, and then isn’t satisfied until it’s done right.
We value a person’s ability to identify opportunities and drive projects from ideation to production, often collaborating with multiple people along the way. They shouldn’t need anyone to hand them a specced out project, or babysit the project while they’re working on it. We think deeply about this quality, and consider these three scenarios for any member of our team, the last of which we always optimize for:
Bad scenario: They only work on exactly what they're told to, and if someone isn't watching closely or delivering specs in great detail, then the project is likely left unfinished or shipped in a way that doesn't make customers say "wow".
Good scenario: They aren’t satisfied until a job is done right. Nobody ever says "I wonder how that project is going - I haven't checked in in a while" or "I hope they thought through these 5 subtle details."
Great scenario: In addition to the “good scenario”, they actively contribute to our product roadmap. They identify what to work on, consider trade-offs between different tasks and implementations, and drive us to amazing solutions to problems we didn't fully realize we had. Everyone on the team looks up to them and intuitively thinks of them as a real owner.
Customer Comes First
Some companies have a sales-driven culture, some an engineering-driven culture, and others a design-driven one. We have a customer-driven culture.
Everything we do is motivated by the question: "What can we do to deliver real value to our customers?"
As engineers, we bear the ultimate responsibility for what our product does and are expected to fully understand the mindset of our clients and their daily struggles. We collaborate very closely with the business team and regularly listen in on customer calls (we aim for once a week). Our single engineer-cum-product-manager leads the effort of turning these learnings into a roadmap, broken down into actionable tasks. We then meet every two weeks to refine, prioritize, and assign those tasks. We think of product development as an engineering function and strive for everyone on the team to have the necessary exposure and latitude to be strong drivers of customer happiness.
Wears Many Hats
We need people who are able and excited to get their hands dirty with anything technical.
We don't believe in technical specialists at this size. Small startups change very fast and it is important that we are able to put our efforts towards the opportunities that are most critical to our success. That being said, we are eager to leverage a person’s passion or interest in a specific area. It is normal for engineers at Wove to fall in (and out) of niches. The real expectation is that everyone has a broad range of skills and *can* work on anything if needed.
Impressive Team Members
Every member of our team is impressive - not because of where they’re from or what’s on their resume, but because of what they do and how they impact the team.
We expect to be amazed and inspired by every new person. We know from experience that this can happen in many different ways. However, the end result is always the same - the team feels disproportionately stronger with them on it. This is a big reason for why many of us joined Wove. Much of the team is made up of people who have worked together in the past, had extremely positive experiences doing so, and valued these experiences highly enough to follow each other here. Ten out of the 17 members of our current team know at least one other Wover from beyond the company.
This does not stop at our immediate team. We are similarly impressed by our investors, who are industry veterans with a wealth of experience, and frequently lean on them for guidance. We are a well-funded Series A startup that has raised $12mm.
High Quality Code Base
Trading off elegance and expediency is an everyday activity; compromising on quality and technical firefighting are not.
Choosing how to tune the knob between expediency and elegance is one of the toughest (and most fun!) types of day-to-day decision that engineers face at a fast-paced early startup. However, we believe that this tradeoff is correctly achieved by compromising on the requirements of a problem or the generality of a solution, not in the quality of a system.
We have a high bar for robustness and have no problem prioritizing and working on highly technical tasks, or tasks that non-engineers would have difficulty understanding. We are constantly challenging each other to write better code, improve our processes, and generally improve ourselves and the codebase. We are intentional about what we build and spend lots of time up front designing solutions and choosing abstractions before we dive into a project. As a result, we have a clean codebase, have very healthy coding practices, and spend very little time fighting technical fires.
It's not just "okay" for people to speak up, it's expected.
Everyone's opinion at the company is extremely valuable. We are all here working together to build a company. This means that it is everyone's responsibility to speak up about what they see from their vantage point, and foster an environment where others are able to do so too.
We believe our success as a company depends on our ability to learn and correct ourselves. This necessarily requires us to be proven wrong about our prior understanding and to seek alternate perspectives. This doesn’t make us feel uncomfortable.
Our desire for open communication applies across teams. The engineering and business teams are expected to understand each other and collaborate on a day-to-day basis. We have a weekly team meeting where each person reports on what they’re working on, asks questions of each other, and stays up-to-speed on what’s happening elsewhere in the company. One of the prime advantages of being this small is that everyone can still fit the whole company into their brain at once. It would be a shame if we failed to capitalize on that advantage while we still have it.
Promotes from Within
You don't need permission to own something at Wove.
One of our absolute favorite things is when an employee joins Wove, identifies some whitespace, and then reaches out to grab it. A good example is when Armaan joined our team as a Software Engineer. At the time, we had no PMs or formal product owner of any kind, so he immediately took this role for himself. Armaan took ownership of our product roadmap and started making decisions about how our product should evolve over time. He also made himself an indispensable resource for the rest of the engineering team by helping us be organized, keeping projects on track, and constantly challenging our assumptions. Less than a year after joining the company as an engineer, he was promoted to VP of Product & Engineering.
Our hope for every new hire is that they'll impress us with their level of ownership and execution. One of the most important responsibilities of our management team is to recognize these people, and acknowledge their contributions through promotions, raises, bonuses, equity bumps, and beyond.
High Employee Retention
We've been around for 4 years and nobody has ever quit.
This fact stands by itself and speaks volumes. It is likely a result of how much we enjoy working with one another, and our incredibly difficult hiring process. We hire very carefully and deliberately, have very high standards, and feel like a closely guarded family. But once you're in, you're in. If you’re interested to learn more about our product, our team, or how you might become a part of our team, reach out.