• Moved to serverless architecture based on AWS Lambda, while also utilizing several other AWS technologies such as SQS and SNS.
• Incorporated GraphQL into our API ecosystem.
• Launched a data warehouse based on Redshift, Periscope, and dbt.
• Productized frameworks such as OSQuery and Kollide Fleet that can provide organizational device information quickly and accurately.
• Develop a chat middleware that allows us to integrate with any chat platform.

Completing our migration to serverless architecture and prepping the platform for scale in all layers - microservices, micro FEs, multiple database solutions, frameworks supporting event-driven architecture, all with high reliability and observability.

1. Moved to serverless architecture and lay the foundations of a distributed platform. While there's a learning curve and added operational complexity, this sets us up for scaling and allows us to dive deep into AWS technology. We've got several service and lambda functions live, and some key pieces of our architecture built using top AWS tools.
2. Established SRE as a foundational platform team + as a lifestyle for our engineering teams. We brought in some key SRE minds to help us with the right tooling and thought leadership around site reliability, observability, traceability, and beyond. We set each team on a journey to implement the 4 golden signals (see Google!), and we continue to both refine our philosophy and add resources to support industry best practices.
3. We've gone through a journey of rebuilding our agile operation. We gathered feedback from each and every team, learning about best practices and pain points. We've refined our ceremonies, our approach to agile (build-measure-learn!), our tooling, and our metrics. We're excited to see the growth in efficiency and team happiness this should bring in the coming quarters.

We run a 2-week sprint Scrum. We share best practices and a general framework, and let the teams customize their practice based on what works best for them.

Typical cycle is grooming, planning, stand-ups, and retros. We're experimenting with basic scrum-of-scrums for cross-team communication.

Our teams went through a deep analysis as of late of all that works and doesn't work with our agile, and we've greatly optimized our process and tooling.

Our focus this year is on tighter MVP slicing, and pre-established iteration on all sizable projects, so that we ensure feedback loops have space, time, and resourcing, to be executed profoundly.

Contract testing is key for us, and we're working to expand our coverage. The reason why this methodology is key is because one could never cover all the use-cases of each service with automation - it would be heavily time-consuming, and there will always be forgotten cases. But with contract testing we ensure that every use case that is actually being consumed (as opposed to theoretically possible) is covered and protected against regression.

We've also established integration testing with Cypress as a middle ground between unit tests and acceptance tests, allowing us to test business-critical scenarios while still mocking certain elements and keeping to high performance execution.

There are no project managers. We are proud in how intertwined our Product/Engineering teams are. Engineers, Product Managers, and Designers - all share the power to change management style and make decisions. Teams gather as a whole to work on their quarterly roadmaps. Leadership provides alignment and business goals, but translating those into Prod/Eng activity is done through brainstorming and negotiation, largely driven by each team and its members

Unit, Integration, and Contract testing are the top 3 for us. Teams are in charge of the quality of the components they own. We're working as a team to increase technological support for testing and automation.

As often as they need to, is the general rule. Teams are free to deploy to Production as they see fit. We trust our feature flagging system to allow for Continuous Delivery, and we work with business teams to expose customers to new functionality as necessary.

Technical debt and platform improvement is baked into our sprint work. It's budgeted on a regular basis, and you don't have to fight for it. I'd say about 20% of the work we do sprint to sprint is dedicated to off roadmap work.

We have ~30 people with a lot of openings. We are aiming to have a team of 50 people split between NYC and Argentina by the end of 2020. We currently have ~15 people in NYC and ~20 in Argentina.

There’s no shortage of work to be done within SRE! On the tech front, this year we are looking to migrate from Ruby on Rails (Heroku) to Python on Lambda (AWS), improve the architecture of our serverless cloud infrastructure, and improve the reliability and scaling capacity of our MDM-as-a-service offering (which is expected to grow by about 10x over the next two years). To do this, we are employing infrastructure-as-code tools such as Terraform and Serverless Framework to manage Heroku and AWS resources (Lambda, RDS, SQS, and EC2), and developing new technical solutions for de-coupling infrastructure and resource management from the development chain.

Perhaps even more important than the technical stuff, a continuing focus for our team will be practicing SRE at the cultural level. While tooling is certainly important, what separates SRE from “DevOps” is a certain mindset that everything can (and should) be measured, and those measurements should be used to give continuous feedback on service reliability to everyone in the company. With our brand-new SRE team, we are helping to encourage this mindset within engineering at every level of our stack and the infrastructure it runs on. This will require significant effort in building and improving observability, monitoring, alerting, and incident management processes, along with all the technical bells and whistles that come along with it.

We run cross collaboration teams, so here is a snapshot from three of our frontend teams working in different areas.

Team 1: Our primary goal this year is to mature our micro-frontend infrastructure. We're building a component library on top of a shiny new design system. Storybook is the foundation for our FE design system. We're playing some of our BFF (BE For FE) with GraphQL. We're paying extra attention to performance and stability, and building observability and automation with DataDog and Cypress. We rely heavily on React and have little to no FE legacy codebase.

Team 2: We'll be looking to improve our UX across the Platform, and continue adding value to the platform by exchanging manual work we've been doing for our customers with platform functionality.

Team 3: We're expanding and improving our home-brewed RTS software so it can provide help desk functionality as well as specialized IT-related UX.

The Core BE team, along with BEs on all agile teams, have helped us migrate from Ruby/Heroku to Python/AWS/AWS Lambda this year. The list of services we've got on Production that's already based on these technologies is growing fast. We're using RDS, Dynamo, and Redis, to solve our data storage and caching needs, choosing the right solution for each problem. In 2019 we've experimented with Node and Go, and believe polyglot programming can play an excellent role if you use it at the right spots. We rely on SNS and SQS for cross-service data hydration, and continue to improve our AWS infrastructure to serve our growing scalability needs.

The Data Team is responsible for laying the foundation for a data-driven product culture at Electric. In 2020, a big emphasis for us is partnering with the product and design teams to improve the way we capture and structure data in our product, so that we're set up to pursue machine learning opportunities in the future.

We also play a role in each feature development cycle, ensuring clearly-defined metrics are available for everything we build, and that the insights we need to make decisions are at our fingertips.

To support all of the above, we rely on a modern data stack, including Redshift, dbt, Airflow, Segment, Stitch Data, and Periscope. Our most pressing data engineering challenges involve making sure we can deliver timely and accurate insights despite the complexities of our distributed microservice architecture.

Own your roadmap. Help scope, plan, and deliver on time.

Take care of your people. Ensure your team is set up for personal and professional growth. And, clear any roadblocks that are blocking their happiness or performance.

Clear technical direction. Make sure your team has the technical clarity they need to do amazing work. Especially when it comes to keeping multiple teams in sync.

Ensuring the engineering team is doing their best work on a day to day basis.

Provide clarity around our technical direction. You are a leader within your technical focus, we need you to provide clarity and direction.

Solve complex and/or urgent problems.

Communicate across the engineering team with other tech leads for alignment on high-level platform design.

We want our engineers to advance without having to go into the management track, and for that we have an IC career ladder offering titles such as Staff Engineer and Principal Engineer, equivalent in compensation to management roles. In addition, we care deeply about the Tech Lead role, which Engineers (senior and above) can serve for their teams. This role focuses on technical leadership and day to day guidance of engineers in design and implementation, without the individual having to carry non-technical management responsibilities.

It varies! We try to go out as much as possible and encourage everyone to do so. Many of us gather back at our kitchen area and eat together. It is also not uncommon for our leaders to take someone out for lunch, to enjoy their company and provide recognition. We make sure all team members get such opportunities as often as possible.

Yes. We want engineers to have access to professional development and to the latest and greatest that's happening in their technical field. We ask that engineers have a goal before they go, and be willing to share learnings when they're back. And then we do our best to approve conference requests - we've done so with great success as of late.

An Engineering Manager's role:

1. Own the roadmap
2. Take care of your people
3. Provide technological direction

An amazing manager aligns those three things (especially 1 and 2) as best as possible, to promote the business goals at the same time as promoting the individuals that trust in the manager with their career and their growth.

An amazing manager balances giving guidance and aligning the team with company goals along with giving freedom, a sense of ownership, and safe ground to experiment and to learn.

Empathy - for the people, the business, and the customer.

Ownership - as a personal approach and as a role model for others.

Thinking Big - see the big picture, know what role you're playing in the larger scheme of things, optimize with context rather that in vacuum.

Positivity - as managers, to a degree we give up the right to complain and to be resigned. Instead, we see the opportunity in every need or shortcoming. We guide our team to hope and mutual sense of pride, ambition, and solidarity.

We work out of a WeWork building in NY. We have an entire floor with an open office design and meeting rooms all around.

We ask the candidate for their language of preference and in that language we ask them to solve a question on an online code pairing tool. We usually use repl.it or codesandbox.io. We look for candidate’s abilities to parse the problem, communicate their approach and solution clearly and their ability to break down into smaller pieces, testability and extensibility of their solution.

No, we want to learn how you think and talk about how you approached a real world problem. We do not expect you to memorize anything or whip out perfect code.

We plan to hire ~14 engineers in NYC in 2020. This will bring the team in NYC up to 25 people. We also plan to hire around 8 people in Argentina to bring that side of the team up to 25 people as well.

Awareness: Someone who cares about the context and wants to answer questions like: "why am I working on this?", "who is this for?", "why is it important?", and "how far should I go with this?""

Ownership: Someone who owns the roadmap, cares for our commitment, plays a role in slicing MVPs, and thinks about what value we can deliver and how fast.

Curiosity: Someone who stays in touch with their profession and helps us experiment and innovate based on the latest and greatest.

Empathy: Someone who deeply cares for their teammates, our customers, and the company. And, someone who can see things from others' points of view and can make balanced decisions.

No, we would do a remote interview over video conference in the case of someone relocating.