We chose this as our first value because that’s what the data revealed, and is a value shared by the clear majority of our engineering organization.
(By the way, our data team ensured that we sampled our key:values in randomized order so there would be no artificial clustering!)
Our engineers are organized into multiple agile teams. A product owner/manager handles the product research, defines and prioritizes feature stories, and communicates with customers, while the scrum team of engineers execute the lion’s share of the work. These teams are supported by the quality, design, data, and techops teams. To that end, each product owner ensures that efforts are aligned with business/customer values, with each sprint sized appropriately to that team based on its historical performance. Rarely do teams overcommit, enabling a us to run marathons over releases than burning out over sprints.
Work hours are relatively flexible with pre-agreed standup times and scrum meetings, dependent on the internal planning by the team. Working together remotely is standard fare as we’re empowered using modern collaboration software (JIRA, Zoom, Github, etc.). We have four offices (New York, Toronto, Long Island, Lexington) across two different countries (US and Canada) and a handful of entirely-remote contributors.
We practice inclusion wherever possible.
This not only means speaking openly with each other about our work and its challenges, but seeking constructive feedback and input from other team members both inside and outside of the engineering organization. During our company-wide town halls, we encourage our newest employees to ask the most colorful questions during open Q&As. Further, we promote transparency across the engineering teams where we openly share everything we can.
While each of our facilities is slightly different, they’re all variations on the open office-style plan with plenty of places to duck-and-hide for a quieter/solitary environment. Often, engineers will “go turbo” for a day or two and work remotely, either from home or a coffee shop.
Impressive Team Members
One of our new hires’—and candidates’—most common unprompted exclamations is about the quality of their coworkers.
WorkMarket has been around for 7 years and has, especially for a New York-based tech company, kept a low profile. However, we have an incredibly strong and experienced team. (You are free to find us on Github/LinkedIn, and reach out! We have alumni from Google, Spotify, NYTimes, Aol, and many many others.) We focus on diversity and engineers from different ethnic backgrounds, gender and age to promote best thinking coming from different origins.
Our investor and board of directors roster is also impressive, including Fred Wilson of USV (our first investor/board member) and Seth Levine of Foundry Capital (our latest investor/board member). Accenture joined our latest round, and they have been a wonderful rubber stamp on the validity of our mission and have been excellent financial partners in our journey.
Safe Environment to Fail
We’re constantly experimenting in new ideas and inventing new technologies on an ongoing basis to meet the needs of large enterprises.
Sometimes, these experiments do not yield the results we desire—or simply don’t work— but we encourage experimentation and failing quickly because learning from these is what enables future success.
In our experience, failure is rarely a direct function of the individual contributor but rather a process inefficiency that needs to be remediated. To diagnose the issue, we practice blameless retrospectives to understand what happened, how to improve, and communicate our findings to the team. We look to continually improve our output.
For example, we will push out early software under feature toggles to test and observe customer usage with production traffic. If the experiment and associated a/b tests prove to be successful, we’ll expand the rollout accordingly. On the other hand, if the experiment fails we put the idea on the shelf and move on.
Flexible Work Arrangements
As discussed, Work/Life balance is important to us and we want to hire the best talent that’s available to join our team.
While there is a slight bias towards having people at the office to take advantage of high-bandwidth face-to-face meetings, it’s certainly not a requirement. Some engineering team members are exclusively remote. This level of flexibility and diversity prove to be effective and a win-win.
People are generally expected to be available 10am-5pm in their respective time zones and in practice, this holds true. Some remote folks work at odd hours, but so long as they are communicative about their whereabouts and make required meetings, there’s not much issue.
Additionally, team members have an on-call rotation to handle any platform issues that may come up in off-hours.
Committed to Personal Growth
WorkMarket believes its people are our greatest asset, therefore personal growth is an important tenet in our values.
While WorkMarket has budget allocated for training, conferences, and the like, a great deal of the personal growth happens through mentoring, both through peer-to-peer and manager-IC relationships.
More remarkable is how much the individuals at WorkMarket value professional development. Unlike most companies where Human Resources is the main driver behind professional growth and educational opportunities, many of the growth initiatives at WorkMarket are self-organized (i.e. grassroot). Management supports ands foster these initiatives with the budget and resourcing as needed, but they are largely driven from the bottom-up.
One example is the emergence of internal talks, a speaking opportunity outside of the normal sprint demo, product-centric flow. It was started by a member of our engineering team, and we maintain bi-weekly open forums for presenters to get help, coaching, and feedback on improving presentation style and materials. It’s an informal workshop, and it works. Members have gone off to present at other meetups and industry events, and have even contributed to technology publications.
Uses Agile Methodologies
Our engineering organization follows a few, related sprint-driven methodologies to work.
The following are generalizations, but help paint the picture:
Sprints are keyed every 2 weeks with releases pushed out every 3 sprints. This lets us deploy significant customer-facing features about eight times a year. This is remarkably fast for an organization of our size whose primary tech is built in a monolithic codebase. (It’s worth mentioning that we are in-process of disassembling that monolith into a microservices architecture as fast as we can so we can iterate and build even faster.)
Feature Teams work on scrum, TechOps on kanban, and Data somewhere between the two. JIRA is our system of record and allows these differing agile universes to play nicely together.
Our product roadmap and vision is usually fleshed out way in advance of the engineering sprint cadence, allowing us to have a very precise idea of what needs to get accomplished when, even if all the finer details haven’t been worked out yet. Additionally, sprint planning accounts for work planning, and we’ll occasionally spike work in a sprint to ensure we understand the costing of future work. We try to minimize planning misses and unknown technical debt.
In the past 18 months, we’ve added 50 people to the product and engineering organization. We work hard to get new hires to deploy code as quickly as possible, usually within their first sprint and many their first day.
Team is Diverse
WorkMarket is committed not only to diversity, but inclusion.
We are not looking to “check the box” on hiring quotas. We truly want to build a team that brings a wealth of perspectives and this is possible only through committing wholeheartedly—full stop. While we are ahead of industry benchmarks for diversity, we don’t think we’ve gone far enough and are digging deeper. We’ll know we’re successful when our ratios reflect the general populations from where we operate.
On that note, we are aware and acknowledge that unconscious biases are reflected not only in our population, but in our facilities and culture. When it’s called out, we address it, whether it manifests in interview questions, dress code, chosen team building activities, and pronoun usage. A quick example:
When WorkMarket HQ moved offices, we had new conference rooms to name. We picked “famous technology inventors” as our naming convention and blindly marched down the path towards the hackneyed trope of white dead dudes. The names were a hasty—and frankly a lazy—decision, and a number of people spoke up. We replaced one “white dude” with Hopper, named for Grace Hopper, (which is where I am typing this sentence). But, we didn’t go far enough. About two months ago, we built new conference rooms and revisited the conference room names; all the new rooms are named after less-recognized inventors, more representative of our populations, and and we’re about to replace “Edison” with “Easley”, named for Annie Easley who worked at NASA and recently popularized by the movie Hidden Figures. We are, however, keeping Tesla.
Our official diversity policies have not been fully fleshed out, though there’s always been a strong push for it from hiring managers. Notably, a diversity and inclusion council recently formed—its creation wasn’t a mandate or even recommendation by any executive, but it grew out of the shared goal that we, as an organization, can and must do better. This council will help provide guidance for official WM policy, and has the full support and commitment of the executive team.