Story Tellers

Posted on 28 August 2015

by Taylor Pechacek - Product Manager

Software requirements are a communication problem. Any organization that builds or uses software, which is growing more common in today’s world, must learn how to communicate what they actually want to build with those who can actually build it. This is where product management fits in within the product team; to help capture, organize, and distill this information from multiple stakeholders into actionable requirements that can be understood and built by engineers.

It’s important to note that this communication is not one-way. It doesn’t always come from stakeholders down the chain to engineering. It is vital that neither side comes to the table looking to dominate the conversation. When the business side dominates, it mandates functionality and dates with little concern for whether developers can meet both objectives. When engineering dominates the communication, the technical jargon replaces the language of the business and the developers lose the opportunity to learn what is needed to bring value to their users.

This is where user stories come in! They are the preferred way within Agile teams to communicate the required functionality of software that should be built in order to create value for end users or customers. The way we write our stories at Maxwell Health is based on a format called Gherkin. This format consists of the title of a scenario and then explains that scenario by answering each question of:

  • Given …
  • When …
  • Then …
  • And …

This allows you to write stories as you would normally explain them, while giving context and autonomy to engineering teams so they can build them in the best way possible. Let’s dive into an example!

Say we want to add a new demographic field for an employee using Maxwell Health that asks whether they are left or right-handed. 

Scenario: New demographic field for an employee - Are they left or right-handed?

Given I am an employee

When I am asked to enter demographic information

Then I will have a field called “Left or Right-handed?” as an option to input

And it will be a dropdown with 2 options: “Left”, “Right.”

And it is not a required field by default

And it can be made a required field by a Master HR Admin

It is easy to interpret this requirement and understand what needs to be done. Engineering can take this, ask further questions if they need clarification or refinement, and then implement it in the best way possible. This is a very simplified example. We would normally expand on this and answer further things like what is the default value, how does this show up on reports, and possibly provide some testing instructions at the bottom.

One important thing to remember when writing stories is how we can test this! We don’t have time to go into that here, but meeting the “Acceptance Criteria” or tests, are how we know this feature has the intended value we want to deliver and it’s ready to ship for people to actually use.

So, next time you are thinking about that new feature or small improvement you would love to have either for yourself or a customer, try writing out what it would look like using the Gherkin method above. At the very least, it helps you think about everything that goes into one simple feature!

Meet Our Interns - Will Corbett

Posted on 26 August 2015

by James Hrisho - Information Architect

Next up is Will Corbett, a Product Strategy intern who joins us from Harvard. He recently went back to school but we had a great time working with him.

Let’s get to know Will!

What and where are you currently studying? What has been the most interesting course you’ve taken so far?

I am currently studying Psychology and Computer Science at Harvard, with a focus on Decision Science and design. In terms of the most interesting course… I’m stricken with the condition of being fascinated by just about everything there is to learn. I’d say the most intellectually engaging course I took was Philosophy of Psychology, where we broke down the very notions of consciousness and reality. We asked weird questions like “what if you slowly replaced every neuron in a person’s brain with a quantum computer, such that it retained all the same functioning of a human brain, but bit by bit went from being made of organic to synthetic material? At what point would this person cease to be human/conscious? Does that point exist?” I thought that was pretty cool.

What are you working on at Maxwell Health? What have you learned so far?

One of the reasons I love this internship is that I get to wear a lot of hats, most of which I have absolutely no right to pick up in the first place. I shouldn’t even be in this hat store [apologies for the lame metaphor]. My mission for the summer is this overarching notion of “customer insights”, which means helping Maxwell quantify objectives as they relate to our customer base and then using data to test whether or not we are meeting those objectives. Step one consisted of meeting people all over the company to understand their data needs and synthesizing those needs into a conceptual “data dashboard” - what metrics one might see on a screen representing Maxwell’s daily pulse across several Key Performance Indicators. Next, I helped create (and in some cases began carrying out) frameworks for addressing those data needs, including web analytics, analyzing metrics from Titan, usability testing (we’ve already done more than 10 sessions!!), and surveying our HR Admins. I have also helped Inessa a bit with research and strategic planning for the next version of Titan.

What are you looking to do after school?

Something like this? I love solving important problems with ambiguous paths to success. I thrive at the center of human decision making and technology. I am fueled by the passion, energy, and good natures of the people around me. In essence, I want to use psychology and technology to tackle a big problem with a kickass team.

How will your time at Maxwell impact your next semester?

Well firstly I’ll have a lot more FOMO than ever before. Seriously, I can’t say enough how enjoyable and fulfilling it’s been to work here this summer, and it sucks that this internship has to stop so soon. I’m kvelling and kvetching. But if I staved off graduation to work here for year, there’s no way I’d ever head back for that degree. Better to finish up this last year, made all the better for how much I’ve grown as a result of this job. Mainly, I have a stronger sense of where my strengths and weaknesses lie: I will pursue more opportunities to apply decision science and develop my product strategy, UX, and creative problem solving skills; I will also practice managing my expectations and breaking up big challenges into smaller, more actionable pieces, and will try to beef up my quantitative analytical skills. Additionally, I will try to tie all of my work back to social causes that matter, which has been one of the most fulfilling parts of working at Maxwell.

How did you hear about Maxwell?

I stumbled out of class just in time to make the tail end of a startup career fair in the Harvard iLab. Nearly missed the shuttle! The Maxwell name and logo caught my eye, so I struck up a conversation with the glamorous rep at the booth. Kelsey laid down the pitch, and my eyes lit up. If I (or Taylor, or someone else) haven’t geeked out to you before about this, here it is: Maxwell’s product is the PERFECT fit for applying insights from decision science, nudging, choice architecture, etc - all the stuff I obsess over. I was enthralled. I emailed Kelsey that night, she got me on the phone with Vinay a few days later, Inessa had me in for a few interviews in the coming weeks, and there you have it!

What is your favorite dishwasher brand and why?

Brandon’s random question was way cooler.

What would your advice be for someone looking for an internship at Maxwell Health?

The same advice I give to everyone who wants a job for reasons other than / in addition to cashmoney (not that I necessarily know what I’m talking about) - be yourself, steadfast and resolutely. You will land the right job opportunities for you if you lean into your passions and competencies, pay attention to what’s out there, and seek genuine connections with other people. That last part is probably the toughest to fake. I think that to establish the types of connections that lead to fulfilling, good-fit jobs, you need to first understand and be at peace with who YOU are. No small task. From what I can tell there is always more work to do.

Key Tenets for a Successful Hack Day

Posted on 04 August 2015

by James Hrisho - Information Architect

Whole Team Meeting

On July 23rd, our engineering team had our first ever Hack Day. This was a whole day for all developers and quality assurance people to self-assemble on teams to work on any project they want to - culminating in a demo session at the end of the day. The teams were actively encouraged not to use this time to get ahead of our backlog, but rather, work on pet projects, prototypes using cutting-edge technologies, and generally creative approaches to problems.

Preparing for the event

We announced the Hack Day to the full team about a week before the event, giving those who didn’t already have a project in the back of their head time to think about what they wanted to achieve. We then collected those ideas in a spreadsheet with a signup portion. People inspired by a project then joined that team and potentially could begin planning with their new team members. In addition to the spreadsheet, I put together a Github repository of APIs and SDKs from AWS, Github, Google Apps, JIRA and HipChat. We use these tools regularly and many of the project ideas included potential integrations. If you are planning a hack day for your team or a general hackathon, having these tools in a centralized place helps get a team moving right away. Lastly, we decided on some key tenets of the day:

  1. Failure is perfectly fine. We are exploring new ideas and failure can be part of that.
  2. Your project might not make it to production.
  3. Open source your project if it is possible.
  4. Try to have something to demo by the end of the day.
  5. Try to work with someone you don’t normally work with and don’t work alone.
  6. This should go without saying – but have fun!

With our tenets set, our resources assembled and projects mostly planned, we were ready for our event.

Day Of


At 8:30AM, the team started to arrive at the office and breakfast was served. People were organizing their thoughts and mostly still waking up. At 9:00AM, we started pitches for each project. While some team members knew what they were going to work on, almost half the team was still up in the air. Each person with an idea was able to pitch to the team in hopes of recruiting members to their cause. Again, a tenet of the event was to not work alone, so it was important for people to put their best foot forward with their pitch. By the end of the pitch session the teams were formed and people got to work.

Tyler pitching his app Will pitching his app Shayna pitching her app Fern pitching his app

Other than a quick break for lunch at noon, the teams worked straight through from 9:30AM to 6:30PM, when our demos occurred. This time was completely uninterrupted, the teams were able to get into the flow and think through their prototypes. The ability to work uninterrupted, allowing a developer to make a large impact into a project in a short amount of time, would come to be the biggest insight from the event.

Anamta Ethan and Will Tommy And Arthur Chris and Zach


At 6:30PM we had dinner and put together the order of who would be demoing. As each team stood up and demoed their work, I was completely blown away by the creativity and the level of sophistication in projects in just one day. The other striking piece was how confident the team was demoing to a large group of people. Demos can be scary, but the culture of humility that we’ve fostered made people feel comfortable. They could stand in front of their peers, show off their in-progress work with a big smile on their faces. They were proud of what they had achieved.

So what did we work on?

Here is a list of just some of the projects:


Maxwell TestBot - An automated testing framework based on Selenium built in Node. Each workflow can be built out using a series of components written in TOML files. Those components then can be mixed and matched to create many different testing scenarios.

Laura and Shayna

MaxVotes - An internal tool to crowdsource ideas and suggestions to our platform built in Ruby. It has a voting system to bubble up the best ideas and a karma system to see who the best idea generators are.

Chris and Zach

4 Strength 4 Stam Leather Belt - Creating a ton of testing scenarios can be tough. This project, built in PHP, helps aid in that by simulating and creating test users in our system en masse.


MongoAdmin - A MongoDB administration tool built in Go. It has the ability to do basic MongoDB functions, finds, find by id, inserts, deletes, and adding and removing of indexes.


PLUG-AND-PLAY - A framework for internal dashboards that lets a developer add different components to make up a large scale dashboard built in Python.

Cory and Tommy

OnDemand - The ability to launch on demand instances of an environment running any branch of code, built with Docker.

Will and Emmma Crushing Code

Mercury - A tool to integrate GraphQL, the new query language format from Facebook with Mongoose and RESTful APIs built in Node.


Tinder for Maxwell Socializing - Built in React-Native, you can post lunch and after-work events, swipe left to ignore or swipe right to commit to come. It also has an internal chat for each event you commit to.

Frank and Will

Maxwell Utils - A dashboard for tools that our internal teams use for administering our system built in PHP.

Emma and Anamta

Bug Reporter - A system that lets anyone report bugs with all of the details necessary to get started: browser version, currently logged-in user, etc., built in PHP.

Wrap Up

After our event we had a short retrospective. It let us review what worked, what didn’t and what we will do better next time. The general consensus was that this was a huge success and that we will absolutely will be doing another hack day in the near future. The work was inspired, innovative, and got people excited about next steps for their projects. We’ve already identified several projects from the event as potential open source candidates and will be introducing those projects as they become open and reach milestones. Other projects will work their way into our system as features for customers and stakeholders.

Meet Our Interns - Brandon Sanchez

Posted on 04 August 2015

by James Hrisho - Information Architect


This summer we were lucky enough to find a few great interns. In a series of posts, we’ll introduce them to you. First up is Brandon Sanchez, a software development intern who joins us from MIT. He’s a big fan of podcasts and singing in an a cappella group.

Let’s get to know Brandon!

What and where are you currently studying? What has been the most interesting course you’ve taken so far?

I’m currently studying Electrical Engineering and Computer Science (EECS) and Science Writing at MIT. I’m only a sophomore now, so most of the classes that I’ve taken have been requirements (i.e. classes like Calculus and Chemistry), although I did have the opportunity to take an introductory EECS course last semester. My favorite parts of the class were learning about circuits (breadboards are weird and awesome) and about Python.

What are you working on at Maxwell Health? What have you learned so far?

I’m working with the EDI Engine, a big part of that project being to compare census files and use their information to form an XML file. I started out doing a bit of back-end work with Python, although more recently have been using Javascript and HTML to do much of the front-end work, creating a dashboard that allows users to easily create and access these files.

This experience has been incredibly beneficial for me as a budding programmer. From a technical standpoint, it’s enabled me to learn languages and frameworks I never knew before, and gain a more developed intuition for coding in general. The best thing about this internship, though, is probably the way it’s introduced me to the software development process. It’s been really informative seeing how all of this work comes together in a really productive, collaborative environment.

What are you looking to do after school?

A great question; I’d answer it more solidly if I didn’t have the tendency to change my answer daily. I guess, being a sophomore, it’s not imperative that I know right now, but that doesn’t keep me from worrying about it. I’d love to do all sorts of stuff, some related to coding, some entirely unrelated. I just wish there was time for all of it. Software development is certainly looking like more and more of a possibility.

How will your time at Maxwell impact your next semester?

I’m now planning on taking a software development course next semester, and I have no doubt that this internship will have been hugely important in giving me an advantage.

Where is the money buried?

I swore to Old Man Withers on his deathbed that I would never tell anybody. Whether due to his tearful pleas or to the gypsy curse that he warned me he had placed upon his buried trove, I’ve thus far avoided that old willow by his crypt. Did I say “old willow by his crypt”? Whoops. Well, the money is definitely not buried there.

How did you hear about Maxwell?

A friend of mine (shoutout to Chris Puchi), who I know from my a cappella group (shoutout to the MIT Logarhythms), also works here, and he told me about it. I scheduled an interview as soon as I could; it seemed like a great opportunity. I was right!

What would your advice be for someone looking for an internship at Maxwell Health?

Go for it! The people here are awesome and you’re going to learn so much. Come prepared to dive into some code, and get ready to crush it. Also, don’t be afraid to ask questions. The other developers are super helpful; they know there’s a big learning curve and they’re always eager to lend a hand.

Big Learnings from our QA To Dev Transition

Posted on 03 August 2015

by James Hrisho - Information Architect

A critical challenge for engineering teams large and small is providing an environment where people can take on new roles and responsibilities. We recently faced this head on when a handful of people on our quality assurance team expressed an interest in moving to full-time development roles. While that transition wasn’t perfect, we had key learnings that will make future movement through our team more fluid and transparent.

Mentorship is critical

Once we established who was interested in moving from QA to development, we paired each person with a senior developer to act as a mentor. The mentor was tasked with finding what their QA mentee needed to learn to be a successful developer at Maxwell Health. With an advocate on their side, each QA person felt empowered and had someone to work with on their journey.

Everyone has their own baseline skill set and learns at their own pace

Our QA team has a diverse background— some have CS degrees, some come from development boot camps and a few are even self-taught. One concept may be a breeze for one mentee while another mentee may have never heard of it, while the opposite is true of another concept. The challenge was identifying where those gaps were and creating lesson plans and development tasks around them. Luckily, we had two great tools to solve these problems: pair programming and online learning. Pair programming with a more senior person gave the mentee an opportunity to see the process from ideation to the solution to released code. It provided a safe environment that could be a learning experience while also delivering features to our customers. Online learning sites like Codecademy and Pluralsight provided endless courses on development concepts. We utilized these tools for situations that didn’t fit neatly into pair programming.

It’s important to backfill your heavy hitters

Once you’ve headed down the path of the transition it becomes increasingly clear that you will need to backfill and train new QA specialists. As most engineering teams know, a great QA is a hard thing to find, so replacing several QA team members was a challenge. It meant interviewing and finding the right people. The rigor that you put into backfilling a role cannot take a backseat, no matter how quickly you want to move someone over to development. The same rigor applies to training those new QA team members you do end up hiring. In our case, the people moving to development have deep knowledge on a large set of projects and have a macro understanding of how everything interacts. They needed to document and do as much knowledge transfer as possible before they were ready to fully transition. The good news is that these people won’t be leaving the organization and chances are, they will still be in the same office space so they can help the new QA folks with questions post-transition.

Timeline and goals need to be established

A clear timeline for a transition is key. We tried to set goals and check-in points internally that we could use to get a sense of each member’s progress. Backfilling roles is the challenge here. Try to build this candidate search period and the training of that candidate into your timeline. For goals, we would suggest having a sheet of agreed upon skills that make up a junior developer at your organization. Some examples would include a working knowledge of the frameworks and libraries you’re currently working with, a set of design patterns and when to use them, and how to use source control. Having a clear finish line makes everyone involved feel like they are working towards an end goal.

Deep knowledge of the product is a great foundation for a new developer

By transitioning QA specialists to development, you are unlocking top talent. As I mentioned above, our QA team has deep knowledge of our product. In the case of Maxwell Health, that knowledge includes complex insurance strategies, how we integrate with our partners, our development and agile process, and a back catalogue of the edge cases that make administering employee benefits unique. Development concepts are far more concrete and there are established strategies to learn those techniques. By transitioning your most knowledgeable people to development, they are coming in with a head start on how your product operates – something a developer off the street simply won’t have. We benefitted from this almost immediately; our QA to development transitioners could identify where potential dependencies between components could occur. They felt confident adding even more complex insurance functionality because they know life insurance intimately and know where a new piece fits in the framework.

To see this transition firsthand is inspiring. It also shines light on other potential transitional moves your team members might be interested in making. Does that person want to move to product management? How about infrastructure? When a team is very small these moves can be easy and more fluid but, as roles are established and teams grow, the switch can be much more difficult. It is a team leader’s role to identify potential moves and to pay attention when someone’s skill set might have a big impact on another team.