We have founded two software startups now and worked at many software companies large and small. Those experiences have shaped the way we organize the engineering team at mabl, which is focused on getting a high-quality product to market quickly. Things are going well so far, so we thought we’d share some of the ideas that we’ve been putting into practice for building a v1 product in the event that it helps you with your next startup. Or maybe you just want to learn more about what it’s like to work at mabl.
I guess this falls in the “easy for you to say” category but in our experience, in an early stage startup, it is more productive to have a smaller, senior engineering team than a large junior team. Based on past experiences, a senior development team is less likely to make fatal technology decisions – those that take so much time and effort to unwind that your product development comes to a halt. At mabl, we have a senior team that is very self-directed, which allows me, for example, to spend time on other stuff, like writing blog posts. Hire senior and you are less likely to assume technical debt that you can’t repay and you’ll avoid the dreaded “rewrite”.
One of the most fun parts of working at an early stage startup is that so many of your decisions have a profound long-term impact on the company. When we are evolving so quickly it can be easy to overlook the fact that some decisions are harder to change than others. We have learned (the hard way) the importance of treating major decisions, in particular those that relate to the core technology stack, data model, information architecture (IA), as distinct projects that deserve real staffing, time, and research. Think carefully before defaulting to the programming language or cloud platform that your first or second engineer happens to be most enthusiastic about and iterate on both your data model and IA until you are confident that they are as simple as possible.
Spending time on these activities can feel uncomfortable in the early days. For example, in our first few weeks, we spent many hours in (sometimes heated) discussions about our data model. That investment has paid off; the data model is still fundamentally intact after 5 months of development. At times you might say to yourself, as I did, “I’m paying developers; they should be spending their time writing code,” but a few extra days comparing notes with other startups, prototyping, and debating options as a group can save you months or years of development time later.
This is a controversial topic, but we find it easier to create high-performing engineering teams if everyone is always in the same physical space. This makes it easier for people to pair, have ad-hoc design discussions, solicit/receive help when they get stuck and generally build relationships. At mabl, we don’t work from home (other than the periodic delivery/childcare issue/plumber visit/etc.) and everyone is generally in the office. Even one remote employee changes the team dynamic considerably, limiting where/when team discussions can happen, making it more difficult to brainstorm and whiteboard. We realize that many startups do a great job moving fast with remote teams; that’s not the arrangement that works for us.
If you’re asking people to come into the office every day – some with long commutes – the office needs to be a great place to work. We think it’s worth investing in a location that is central for the team (and hiring pool), has good light, has enough space for people to work, eat/drink, collaborate, etc. We started with a great, affordable WeWork location before settling in at our long-term office in downtown Boston.
mabl is centrally located
Daily stand-ups serve many purposes for us. Obviously, they help us maintain a shared understanding of what everyone is working on on any given day and whether anyone needs help. Stand-ups also give us a chance to make rapid course corrections; we all try to be on the lookout for cases where people are doing work that can be safely deferred or done more efficiently using a different approach. Selfishly, stand-ups also give my co-founder and I opportunities to share information or context with the team without scheduling separate meetings. And doing them right before lunch gives everyone extra incentive to be concise.
We never skip a stand-up
The startup journey isn’t a sprint because it lasts too long for you to be running at full speed constantly without getting burnt out. It’s also not a marathon, because sometimes you need to be running at top speed. We like the analogy of a relay race. We start by posting our quarterly goals on a giant poster the wall. At any given time, one or two people are carrying the baton for the company–working on the thing that is on the critical path in our pursuit of those goals. In fact, at mabl, we have actual race batons that we pass during stand-up (you’ll notice Steve leaning on the center meeting room with the baton in his hands above). If you have the baton, you work in a higher gear than the rest of the team, you bring the baton to meetings, and you always start the standup discussion. Trust me; you don’t want to be the one with the baton for long.
At this stage, other than a weekly team happy hour, we find that recurring meetings (1-on-1, team, or otherwise) are extremely costly in subtle ways. First, because the meetings are scheduled, there is a bias for holding the meeting even if it isn’t the most important thing for the attendees to do at that time. Secondly, because they’re scheduled for a particular amount of time, we tend to allow the topic to fill the allocated time, even if a 5-minute water cooler chat would have been sufficient. Most importantly, recurring meetings force an interruption for all attendees regardless of whether it is the right time for people to step away from their work. In particular, I believe that interrupting a software engineer “in the zone” is akin to waking a sleeping newborn: The building had better be on fire or it’s not a good idea!
A benefit of us all being in the same physical space is that we don’t need electronic tools to help us manage our work. We also try to start each sprint with a fairly clean slate (rather than working through a large backlog). So we ditched Trello for now and use a physical scrum board. We find that it’s easier to talk through where we stand using the physical board. There is also something really satisfying about the act of getting up from your desk to take a card and move it to “complete”. And it adds nice color to the office!
mabl’s scrum board
We try to decompose our work within our sprints into projects that take a small number of weeks to finish and we currently have three small teams running in parallel. Rather than setting a specific timeframe for each sprint, we use stand-ups and ad-hoc conversations to assess whether we are approaching a natural replanning point; typically the point when it feels like most of the team is at a reasonable project breakpoint. More specifically, we look for the following:
Replan when the time is right
Practically speaking, after the first week of a sprint, we start guessing when each team will substantially complete their sprint goals. If it’s at least two weeks out, we hold off replanning. Once we think that breakpoint is a week out, we schedule the replan.
Prior to the planning meeting, I spend time defining tentative priorities for the next sprint. Then I meet with each team member to gather input. We iterate informally on priorities and staffing for a few days. By the time we start the planning meeting, everyone is aligned on the priorities and staffing, so we spend the time developing a plan of attack for each project and clarifying requirements.
At this early stage, we don’t find it useful to formally estimate the effort associated with engineering work. We try to break the big things that we want to do into smaller projects that feel like a few weeks of work, and then we break those down into stories that feel like a few days or less. We find that avoiding estimation, retrospectives, and top-down deadlines helps to create a self-directed team and reinforces the idea of shared accountability. That’s not to say that these won’t be important as we scale and evolve; we know that the team will be excited to rally around major launch events, conferences, and customer needs when the time comes.
While “Minimal Viable Product” may go down as the most-overused buzzword of the lean startup era, we use it too. We want to ship an MVP as quickly as we can. We spend a lot of time thinking about both the minimum scope that we can deliver in our first beta and what we really mean by “viable.” At mabl, we believe code quality is core to product viability, not only because we want initial users to be excited about the service, but also because we believe that quality code will help maintain high engineering velocity. Accordingly, most team members invest 1-2 hours each day doing code reviews for others, and a medium-sized change will typically garner 5-10 meaningful comments and suggestions.
This sounds like such an obvious thing but we have seen time and time again situations where startup teams understand that everyone should be talking to users but go weeks or months without actually doing it, instead receiving second hand feedback. We believe that engineers who have a deep understanding of users and their pain points are able to deliver customer value at a higher velocity, because the translation time for requirements/user stories is much lower. Here’s what works for us:
We also like to initiate new engineers into this aspect of our culture by asking them to facilitate a user discussion on their first or second day, but the jury is still out on whether that is a best practice.
Like many modern applications, mabl relies on a microservices-based architecture behind the scenes. And as with many engineering teams, some mabl engineers spend a lot more time contributing to some microservices than others. We learned early on that the user experience is often lost in translation between the output of one system and the front-end, so unless you spend all of your time in working on the user interface (and even in that case), it can be hard to understand the product experience if you don’t use the product yourself. So we have all agreed to use mabl regularly, and we can already see the impact; the entire team is involved in finding, logging, and fixing issues in production. And as a team, we’re all feeling more accountable for the whole of the product, not just the parts that we are actively working on. Most importantly, we find it easier to put ourselves in the users’ shoes, which makes prioritization more efficient..
One of the mistakes that we made with both of our startups in the early days is underestimating the time commitment that interviewing requires. Collectively, we spend at least 12 hours with each engineer who comes in for a full time interview (phone screen, take-home exercise, 3 paired in-person interviews, debrief). With several interviews per week, this can be a tremendous drain on development velocity–particularly if you factor in the cost of context-switching. We have learned (finally) that well-designed take-home exercises and thoughtful phone screens can save the team a great deal of time.
These are some of the things that we’re doing differently in this first phase of our work at mabl. We expect some of the principles to survive as we get larger, while others may need to evolve to support a larger team with more complex demands. In any case, we expect to continue to focus on building self-directed teams, engaging deeply with users, and being pragmatic about process. We’ll also revisit the way that we approach our work frequently and do our best to make the right adjustments. We’ll be sure to continue to share what we’re learning with you here, so please check back often! Also, we're hiring!