Engineers write code for the backend, frontend, and help define the roadmap.

We encourage and support our engineers to work on projects across all of our products. One week you may help spec out a new feature and develop the API endpoints. Another week, you may be wiring up the redux actions and creating the react components. You will get the opportunity to work on systems that impact our customers and learn new technologies in the process.

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.

Engineers are involved in design and product decisions, defining the roadmap, prioritizing work on a day-to-day basis, hiring, and everything else in between.

We have an informal, “bottom-up” organizational style where all employees participate in making significant decisions. Engineers have significant opportunities to be proactive. As an example, here’s our process for defining our roadmap. We’re a mostly remote team, so we gather in person once a quarter and spend an entire day deciding what to take on next. Every team member will come up with 10-20 proposals, large or small. We then collectively evaluate their benefits and costs and then decide upon a sequence of milestones for the coming quarter.

“Michael McLay publicly asked, in 1994, what would happen to the Python language if Guido van Rossum were hit by a bus.”

Developers are not silos, they can have specialties but the “Bus Factor” (the ability of a company to continue performing despite employees getting hypothetically hit by a bus!), in Loylap needs to be quite high. The higher the Bus Factor, the higher the probability the company can continue to function.

Wearing many hats is important to the overall function of the company, but it also benefits individuals. If a you wear a few hats and a role becomes redundant due to a tech stack change or loss of big client, you can simply wear another hat. If we lose a person, there’s a good chance the institutional knowledge they had won't also be lost, because another member in the company has similar knowledge. While roles can become redundant, people never do.

Developers at Braze are expected to grow their skills across all areas.

On any given day, along with writing code, you may write documentation, provide support for our product, interview new developers, QA a new feature, write product specs, lead a meeting, have a 1:1 with your manager, or present your work to the team. We mix specialists and generalists, but neither is a company value (and the split emerges organically from business needs and scaling). What we do and work on depends on the business needs.

We won’t limit you to one narrow set of responsibilities or role.

We try to encourage growth in our team members’ strengths, while appropriately challenging any weaknesses. We find that drawing hard lines between technical responsibilities can often hinder our ability to move quickly, so we don’t. Do you work on the front end but know how to handle that issue with the API? Go for it! Just send a pull request for the backend team to review. Are you a designer who has experience in web development? Great, our designer is also a front end developer! We fully support individuals who have broad skills. In fact, we think that’s wonderful. For those wanting to round out their skill set, we think our team is a great place to do it. Our current team members come from many different backgrounds and have varying levels of experience with many aspects of our technology stack –– everyone has something to learn and we encourage that everyone does.

You don’t work at Samsara just to code.

Anubhav, a Samsara engineer, is a perfect example of how our team wears many hats. Anubhav joined Samsara the summer after he graduated from MIT and during his first week he was asked to build a sensor to measure the health of industrial machines such as large pumps and compressors. (Fun fact: unplanned machine downtime can cost manufacturing facilities up to $250K/hour!) After just a couple of weeks, he had built a prototype and traveled to a customer site to install the sensor and test the dashboard. Anubhav’s work was then showcased at the next board meeting and our industrial product line was born. Engineers at Samsara have responsibilities that span across customer research, product management, design, and of course, engineering. We want to hire people who like getting involved in a number of areas, enjoy working with various people, and are energized by the breadth of work that exists here.

We are looking for people who aren’t just comfortable wearing many hats, they prefer it.

If you haven’t worked at an early stage startup before, we hope you’ll take the time to fully understand what comes with it. There’s less structure. We don’t have a multi-month roadmap. We want you to help us drive, fill gaps, and make important decisions. You should want to create and build out Precious on your own, not because someone else is expecting you to. In addition to the many responsibilities you’ll juggle, you should also be aware of how influential our next hires will be. Whoever we next bring onto our team will define the future of our company’s culture and product. Hopefully, they’ll also care deeply about how they shape both.

We are growing quickly, so we encourage people to fill the gap and wear as many hats as they want.

Want to learn more about operations and the business side of Flexport? Phenomenal, do it. Learn about their pain points and go build product to solve them.

Kevin built our permission policy system, and single handedly ran our infrastructure for over a year. He flew to our Shenzhen office to improve site performance behind the Great Firewall.

Chase, an engineer who was recently promoted to engineering manager, led our customs team for a year. He spoke with our operations squads and customs brokers on a daily basis. He created the product specs, coded solutions, and assembled the engineering team.

All of our engineers are full stack.

We want everyone to have a general understanding of our system, and for any engineer to be able to fix any bug or implement any feature regardless of which part of the stack it touches. We also expect every team member to have a general understanding of the needs of the business, and to be able to help out on projects that are outside of their core role. As our team grows we’ll have more specialization, so it’s not a disqualifying factor if someone wants to focus just on the backend or just on the front end, but if you’re looking for broad exposure in order to gain experience across the board, you’ll find it here.

We’re a small team, which means we’re all responsible for many things.

Each of our current team members have really diverse backgrounds, so we get to learn a lot from one another. For example, Mark is well versed in music and teaching which lends itself well to his articulate expression of coding problems. And Robert ran a large online community for architecture students which has translated well to customer success and helping rally support for our company.

Perhaps more uniquely, we don’t silo anyone because of their labeled skillset. Action is the great equalizer. Have an awesome idea? Mock it up and show it off, then let’s see how we can either improve it or get it into production. At Monograph an engineer can provide illustration work and a salesperson is able to give design feedback.

While we do have specialists across our entire engineering organization, we want a large part of our team to have breadth and be able to jump in on a wide variety of problems.

We want front end engineers that like to tweak APIs and update backing data models. We want back end engineers who make sure that the client SDKs are easy to use and running efficiently. We want engineers who solve problems at all levels, from the initial product conception to the maintenance and monitoring in production. We think this is important for a couple of reasons:

1. The less isolated engineers are in their particular disciplines, the better they will be at solving problems for our members and for other engineers.
2. We will never have enough people to do all the work we have. Being multi-disciplined (or being willing to try) means that you’ll be working on all sorts of problems.
3. The skills we need today may not be the same as the skills we need tomorrow. As we evolve, we want our engineers to evolve with us.

You’ll wear at least four: engineer, product manager, designer, and end-user.

As an example, one of our engineers focuses on our record collection product. He works closely with operations that does record collection and therefore manages feature requests, designs the product, executes, and tests it. Our hope is to hire engineers who can get behind our mission and understand who our audience is. While having personal experience in healthcare isn’t necessary, it certainly makes you much more effective. If you can empathize and connect with your end-user, you’ll be designing and building a product for yourself. Not only does it make the work that much more meaningful, but it also gives you valuable insight throughout development.

We're a startup, which means there's always more things to do than people to do them.

In our case, perhaps even more so than a software startup. On just the tech team, we cover hardware integration, automation, high-level integration, optimisation, and AI learning systems, to name just a few. Whilst each of the people on our team has a particular domain of expertise, we all pitch in on whatever is required most urgently, be that hiring, building UIs, devops - you name it!

Position works on billable client work four days a week.

On Fridays, we do everything else -- and this can include invoicing, recruiting, marketing, sales, accounting, legal paperwork, planning, and much more. When important projects come up (for example, “becoming a cooperative”), we create working groups of one or two people to make sure everything gets done.

We greatly value all this non-development work. However, we also believe that we do better work when we are able to focus, and we hope to reduce the number of hats each of us wears over time.

If Position’s values sound exciting and interesting, we encourage you to check out our open positions and apply! If you’d like to know more about Position or if you have questions, you can also email us at work@positiondev.com.