Myth Busting: Engineering Edition

 

Blog post by ELP student Atharva Talpade (Computer Science | Class of 2021) Interning at Mighty.com

What assumptions to let go before joining a startup engineering team

This summer I got the opportunity to intern on the dev team at Mighty. I am working on exciting mission driven products that are pulling the fragmented, archaic, and complex personal injury space into the 21st century. This summer, I already have had the chance to learn from incredibly smart and talented co-workers, been able to spec out, engineer, and ship real features, and observe a growth stage startup from the front row. The experience I am having is rich and will serve me well in the future.

One of the most startling realizations I came to at Mighty is the actual definition of a startup engineer. Until I joined Mighty most of my experiences were personal, group projects/products, or siloed projects for companies, so I had very little exposure to professional dev teams. Therefore, before I joined Mighty, I had a much different definition of an engineer than what was reality. I thought professional engineers were almost always specifically focused on just one portion of the stack and the actual tasks were just created by product and ops people with senior devs in the room for sanity checks. I figured their workflow went something like choose task → look at spec → consult with design → code it out in a silo → send it to QA → (if it’s a success) never see the code again. As most startup engineers know, I was wrong.

The best engineering teams are extensions of the product team

When an engineering team is an extension of the product team an integral portion of the company becomes product owners. This means that engineers know that they have not only the autonomy to be helping with product decisions, but they actually have the responsibility to push back and speak up about product decisions. Due to this responsibility, engineers will have the end user more firmly entrenched in mind while reading specs, creating features, and squashing bugs. From my observations at Mighty, a collaborative engineering and product team equals a fast-moving product that truly caters to customers.

Startups make do with the resources they have

Of course, big companies will have multiple teams with several different types of engineers and roles staffed by specialization on each team. Mighty has an engineering team of 11 with two customer facing products and one internal product. They cannot yet afford to have solely front-end engineers, back-end engineers, designers, dev-ops, and QA people and they cannot staff engineers based on each product. Therefore, the Mighty engineering team has to improvise. Like all good engineers, they make things as reusable as possible (for example creating a whole open source front-end library spread across the entire codebase and creating a backend that can be used across products). I also saw engineers take on roles and learn skills to do basic design and QA work. The most surprising thing for me was seeing people who were obviously talented in either backend or frontend do work in the opposing portion of the product with no issues or complaints. Having an engineering team that is comfortable with fluidity in terms of products, assuming new roles, learning new non-engineering skills, and working in a fullstack way lets a startup be lean and aggressively pursue growth.

Dev tools and infrastructure

An under appreciated adjustment to be made when joining your first engineering team is the sheer amount of dev tools and development infrastructure that the team has. My assumption surrounding tools was non-existent because I had no idea how important they were to a dev team. I did not realize how much faster and safer development, bug squashing, and deployment can be with these tools. I think any team or project that does not utilize a smattering of them are not engineering to their full potential. They are wasting mental operations on managing these things manually or unravelling issues that stem from not having these tools/infrastructures.

Joining a startup dev team for the first time can be very difficult, but if done with the right mindset and a great team, it will be extremely educational and helpful for the future.

Please let me know if you have any thoughts or comments – would love to chat. You can reach me at atalpade@umich.edu.