Last year, I embarked on a new adventure with MuleSoft Engineering. It’s been over six months, and it’s been an incredible experience, and I’ve learned a lot. I wanted to share my six biggest insights into what it’s like working here.
What’s MuleSoft? We help businesses become more productive. We provide a platform that helps enterprises connect and orchestrate backend systems they build and/or use, which in turn saves time and money. I work on the CloudHub Engineering team, and we are responsible for running the engine for deploying, running, and managing Mule applications in the cloud.
Why did I join MuleSoft? I wanted to explore enterprise startups but also didn’t want to go to a super early stage startup. Plus, I wanted to explore cloud technologies that I hadn’t had a chance to work with and wanted a role that would give me the challenge and flexibility to learn new things constantly. I’m happy to say that I’ve found all those things working on the Engineering team at MuleSoft, and here are a couple things that stood out to me.
1. Hiring rigor
Hiring is the company’s number one priority, and I could feel this first-hand during my interviews. The process is similar to what you’d expect in tech, but the interviews themselves were pretty intense, which reflects the intense and challenging nature of the work. You can tell that the team cares a lot about the interview experience and making sure the role is mutually beneficial. They spend the time working with the candidate on their schedule and being flexible, as opposed to just trying to hit a quota. I remember telling my hiring manager that I’d like to meet with him once more and two other engineers on the team during the process, which was outside the standard, and he not only made that happen but also gave me space, time, and assistance to make my decision. That meant a lot.
Our CEO, Greg Schott, is also deeply invested and involved in recruiting. I remember the recruiter calling me saying, “Hey! Our CEO would like to talk to you.” I responded immediately, “Sure! ” but also remember several alarms ringing in my head. Why would the top exec at the company want to talk to a non-exec candidate, an engineer no less? I’d never been interviewed by the CEO of a company of our size and scale before! I figured if he’s taking the time to talk to me, then there’s got to be something to it. The conversation ended up being great, I asked some hard questions (or at least I think I did), and it was helpful to hear his responses to why MuleSoft matters and where we’re headed. I realized after joining that it makes perfect sense for the CEO, who is responsible for building and leading a great company, to be actively involved in hiring. After all, it’s the people bringing their experiences, knowledge, and attitude together and executing on a problem that makes or breaks a company.
2. Minimum viable process for maximum productivity
There’s process for sure, and it’s necessary, but I think the intent and approach I’ve seen here is to have a minimum viable process. There’s just enough process that’s biased toward action and keeping your productivity high. If the process gets in the way, kill it. If it makes things more efficient, introduce it. And re-evaluate. For example, onboarding isn’t an arduous process here. Day 1, 0900-1200 hrs, you get a laptop, instructions to get the obvious logistics out of the way, and off you go! You meet your manager, he/she assigns you a buddy to work with to get setup with the code, tools, and access grants to different systems, and you jump right in. It’s more like, get started on a real problem, ask questions, get help, and ramp up along the way. This way, you get to collaborate more with your co-workers, make meaningful contributions to the product right from the get-go, and feel like you’re truly part of the team.
Engineering teams at MuleSoft are small, centered around products, and responsible for running their part of the service, i.e. managing the backlog, release schedules, coordinating with DevOps to get things running on our infrastructure. Before MuleSoft, I’ve worked on teams where Product and Engineering work closely, but this is the first time I’ve ever been on a team that works so closely with DevOps. And it’s not just my team, it’s every team. The team sits right next to us and is always available on Slack for answering questions, troubleshooting, and in general getting things done. They encourage teams to send Pull Requests for making changes to the infrastructure code. We have a mix of fixed and impromptu release trains, and teams get to choose whether they want to get on it or not, and what they want to release. Needless to say, we use a distributed version control system, which in and of itself makes us more productive.
All code is open for any engineer to read and contribute to. Adopting this open philosophy for our internal repos minimizes process and more importantly eliminates the “thou shalt not touch my code” attitude.
It’s not perfect (nothing ever is), but we’re constantly improving our path to production while keeping the minimal viable process as our guiding principle.
3. Leadership is more than management
Someone once gave me the perfect definition of a leader: “A person who can inspire people to follow him/her without asking them to.” There are leaders everywhere here. My teammates, my peers from other parts of the organization, my managers and execs. They listen, they ask the hard questions, they have a very sensitive BS meter, they’re approachable, they guide and help. They expect and demand your honest feedback. Their actions make you want to do better. Talking to leads and architects is just a matter of walking up to them and asking for their time. More often than not, they’re like “sure! let’s grab a whiteboard.” I’ve had several such conversations, some high level, some specific. Some of these conversations have led to actionable items which are in production today. Managers are not just people managers here, but pretty technical too. I’ve had technical discussions with my manager in our 1-1s to help prioritize issues and he’s also asked me how I’m doing and what I’d like to work on next. Both my manager and our DevOps manager get down in the weeds with us when we release and troubleshooting issues and help us without micromanaging us. They apply the right kind of pressure. It’s like driving a car — if you apply too much brake or gas, you’ll slow everyone behind you or overheat your engine. When you drive at an optimal speed, both your car and other drivers are happy. Our managers not only drive pretty well here but let you drive too. They let you own what you work on.
We once had an issue to deal with, and my team got involved. It was not just us and devops and engineers from our BA office but also our execs in the room. And while we did solve the problem, what stood out to me was how we came together as a team in a moment of need. There were no blame games! There were only just-in-time decisions and effective root cause analysis. Our execs rolled up their sleeves and sat down with us right until the end! It seemed like everyone had checked their titles at the door. Just a bunch of engineers bringing their experience and contributing to solving the problem. I got to witness a lot of leadership that day!
4. None of it matters if you’re not learning!
At MuleSoft, I learn something new every day, and it’s awesome. I work with people smarter and more experienced than me, and I get to learn from them and push myself. Our services are polyglot both regarding programming languages and persistence layers. I’ve had to work on bugs and features that use technologies that I hadn’t worked on before, but I still did it because I knew it would all be code reviewed. We’re actually encouraged to take ownership of the products we work on, and that means that if we feel like we need to learn a new technology or framework to get the job done, we do it.
We host hackathons multiple times a year. We have engineering demos every two weeks where you can present something you’ve worked on. Both are great avenues to learn new things, and pick up on keywords to go back and read up on. Being in this state of constant learning does something amazing! Apart from learning something new (obviously), it keeps personal egos in check. Rather than behaving like a know-it-all, you behave more like a student learning from everything and everyone around you, and that applies to people of all tenures and titles.
5. Having fun!
Last fall, we packed ourselves into buses and went to the American River to fight some rapids. It was <clears throat> AWESOME!! We have game nights where we transform one of our common areas into a gaming arcade. We have trivia nights. We have Waffle Wednesdays! There’s really no shortage of activities for people to let loose and have fun, and the company is always open to new ideas too.
6. Giving back
When I joined the team, I didn’t realize the exciting things MuleSoft does in the local community that I could get involved in. In September, we hosted Coding Cup, a free hackathon event for middle- and high school-aged girls, and I was a mentor, which was really fun. We’re giving back to the community any which way we can. We’ve raised money and bought food for our local food banks, collected toys for kids, organized donations to help people in Haiti, and more. I’m glad that MuleSoft is into building meaningful technology that brings value to our customers and the community.
It’s been a fun ride so far, and I’m excited to keep solving some pretty challenging problems with the awesome team I work with. There’s a ton of stuff to do, and I’m looking forward to the future.
Onward!
P.S. If you’re interested in learning more about the team, what we work on, or open roles, I’m always happy to chat, so feel free to drop me a note.
