Parker Lawrence is a full-stack early stage engineer who went North, then West, South, and now Northeast to build his toolkit as a founding engineer in insurtech. Today, he’s helping to scale the infrastructure of the easiest API for commercial insurance at Boston based Herald as a Software Engineer.
Growing up in West Virginia, Parker took an interest in visual art and then ice hockey. As a young kid, he always had a sketchbook on hand with drawings of various cartoon characters, and in high school he played goalie for one of the only four high school hockey teams in the state. Parker’s dad, a Duke alum, was a litigator focusing on energy and environmental law and his mom, a UNC Chapel Hill alum, had an MBA and worked for a natural gas company. Now a dad with two young kids himself, Parker credits his parents as role models who effectively balanced impactful work lives with young kids.
Parker’s path north began when his high achieving older sister attended a Harvard admissions event in Charleston, West Virginia, encouraging West Virginians to apply. She did, was accepted, and off she went to Boston. So naturally a couple years later Parker followed his trailblazing sister to Cambridge. It happened to be the only school he applied to north of the Mason-Dixon line.
During undergrad Parker studied Philosophy but quickly realized he didn’t want to pursue academia professionally. In his spare time he was the President of the Harvard Radio Station, and he played guitar and sang in a couple bands, though he resisted my attempts to obtain any audio or video evidence of this chapter of his life – “It was a bit aggressive. I was pretty into punk and hardcore at the time.” He took some math classes, logic theory, and Intro to CS but did not pursue engineering (yet!).
While considering a couple different post graduate career paths, including taking the LSAT, he did some on campus recruiting. Oliver Wyman, a consulting firm, was recruiting for Analysts in New York with the flexibility to try a number of projects across a variety of different clients. It helped that Parker’s sister had worked there, too!
In the shadow after the financial crisis, Parker started at the firm helping financial institutions comply with newly mandated stress tests for U.S. regulators. He built powerpoints & risk models, prepared reports, and learned technical skills like SQL, R, and VBA. He loved the self teaching aspect of these new skills – reading forums, researching Stack Overflow, and building solutions in a matter of hours. It was empowering, and he could work at his own pace.
After a couple years building up his savings, he wanted to pursue engineering full time and took a leap to attend the newly established Flatiron School. They were a local upstart 3 month coding bootcamp and he enrolled in one of their early cohorts. He immersed himself full time in the classroom, learning problem sets and establishing a good foundation for a career in software engineering.
Parker’s girlfriend (now wife) was moving to Chicago to attend law school, and Parker followed to find his first engineering role in the Windy City. He landed a full-stack role at LiveWatch, a home security platform that competed with Simplisafe. Working as a jack of all trades alongside a handful of other engineers, he built internal tools & data analytics tooling, worked on their main e-commerce platform, and overall learned a ton. He set up a data warehouse for the first time and made live dashboards to own these critical responsibilities for the first time in his engineering career.
Next, Parker went to a larger tech company, Guaranteed Rate. They had a much larger engineering team using Clojure, a language and technology Parker was interested in learning about more deeply. But, after about a year, opportunity struck to join Kin Insurance with some old colleagues, and Parker decided to jump aboard the promising young start-up.
Kin was Parker’s first true venture-backed, hyper growth-focused company, and he joined as one of their early employees, when the whole company still fit into a couple WeWork rooms. They were using technology to help bridge high risk insurance categories like “property insurance in Florida”. It was another full-stack role, but this time he was responsible for standing up a bunch of architecture from scratch. He built out several full analytics and testing services and maintained their internal rating API. And as a part of larger teams, he revamped their front-end customer flow and built out the first version of their policy administration system.
Parker & his wife then moved to New Orleans after his wife landed a coveted Federal clerkship. He found a role with AlltimePower, a venture & partnership of local utility giant Entergy. The board was interested in helping to build alternative, more intelligent uses for their power grid to help maintain power plant efficiency & utilization.
As their first full time engineer, Parker built a two-way marketplace for generator dealers to buy leads and sell remote switches on those generators. The product (and subsequent network) helped create more efficient uses of the power grid using a smart generator network in an effort to create a virtual power plant. The company grew to cover 20+ states with over 100 generator dealers on the platform.
After a couple years in New Orleans, his wife was offered a role in commercial litigation at a Boston area law firm to bring the family back to the Northeast. She is a native of Williamstown and, since they’re both familiar with the Boston area, it sounded like a great fit to plant some roots!
Parker was introduced to Herald founders Matt Antoszyk & Duncan Crystal through a family friend in the Phillips Andover network. They were looking for early stage technologists in the insurance space for their Lightspeed & Underscore backed startup Herald, building the easiest API for commercial insurance. Parker’s sweet spot!
As their first engineer, Parker got to help own the initial Product relationship, DevOps, and spin up all their alert & monitoring analytics. At this point, he knew how to build and apply this playbook for building from scratch.
In the 3 years since, Parker has helped Herald scale their Product and helped focus on horizontal scaling to help the business build new relationships with insurance carriers integrating into Herald’s API. He helps own new features and the process of “what does it look like to add a new integration” while making the process repeatable and high quality. He serves in an individual contributor role but feels like he’s growing with the company, mentoring colleagues and making a positive impact on the team & product footprint for a growing technical team.
In his spare time, Parker is spending time thinking about the future of AI and how to incorporate these new tools into his workflow for maximum leverage. He’s experimented with GitHub co-pilot and has toyed with ChatGPT to write some experimental code, testing the potential opportunities and risks of this new paradigm.
Optimize feedback loops
Any work we do involves one or many feedback loops. One way to structure our thinking about these loops is to break them into 3 broad categories:
- Immediate feedback – info you can collect without relying on anyone else or some long-running process.
- Mediated feedback – involves some other person or process and can’t be gathered immediately.
- Customer feedback – feedback from the person who ultimately determines success. This could be customers, users of an internal tool, a manager, etc.
When starting on a new task, think about what kind of feedback loops you can create across these categories, and follow these rules of thumb:
Rule 1: Make sure you have a plan to cover all 3 categories, as each provides unique value:
- Immediate – Spending a small amount of time to create immediate feedback can save a lot of wasted effort. For example, writing unit tests can often save a lot of back-and-forth with QA teams or users. Or, if you’re working with large datasets, it’s always good to do a sense check of aggregated stats (percentiles, outliers, etc) before passing along findings drawn from potentially bad data.
- Mediated – While immediate feedback is great, it’s hard to overstate the value of getting another human involved. I expect most have seen this scenario play out: you carefully craft unit tests for a seemingly simple change. When the tests pass, you decide to skip manual review. It’s a simple change, right? And you wrote such great tests – nothing could go wrong. But of course, you already know the conclusion, don’t you? Moments after the change hits production, a customer reports a bug.
- Customer – Don’t forget about what really matters – the customer experience. Often this feedback is the easiest to gather, but it can still get skipped if you aren’t careful. Make sure to collect and review usage stats or do customer surveys or whatever is needed to close this final feedback loop. You don’t want to do all of the work getting something into the world and then wait weeks before realizing it’s not being used due to some easily addressable issue.
Rule 2: Move things “forward” toward immediate feedback as much as you can. A couple examples:
- Say you are designing a new feature and one step in the process is for your manager to review the design. Take time at the onset to agree on a checklist with her about how she will assess the design. That way, you can first go through the checklist on your own and move her mediated feedback forward into immediate feedback.
- One way to move customer feedback forward into mediated feedback is to pay attention to your data. Modern technology systems often collect a lot of data passively, either in logs or directly in operational databases. Bad changes that pass standard QA steps can still create obvious red flags if you review the data created from testing.
3 Career Insights / Learnings
Invest In Your Tools – “You spend so much of modern work using sophisticated technical tools like a text editor, programming languages, framework within a language, SaaS platforms, etc. Really make sure you are investing in your workflow(s) and enjoy your tools. Donald Knuth says ‘The enjoyment of one’s tools is an essential ingredient of successful work’”
Adopt New Tech Thoughtfully – “Any time you adopt cutting-edge new technology, you have to make the investment to learn it and effectively be a beta tester of it. At the end of the day, that can add up to a substantial amount of time – time you could be spending solving domain-specific business problems. So often it is better to lean on battle-tested tools.”
Solve Hard Problems Together – “I think there’s immense value solving hard problems together in a pair-programming style, but it can seem harder than ever in a remote world already packed with fatiguing video calls. Use your judgment to identify problems worth solving with a colleague or as a team, and resist the urge to ‘take it offline’ – get into all of the hairy details together.”
Parker is excited to see what the future holds for him at Herald as long as possible. Over the longer term he plans on continuing to specialize in early stage startups. Perhaps one day that means pursuing the entrepreneurial route or bringing technology to the Education space. In the meantime, he’s focused on gaining the best insights to bring to any future experience, growing as a leader at Herald.
If you’d like to learn more about Parker, you can find him scaling technical infrastructure and tooling at rapidly growing Boston based insurtech Herald, taking care of his rapidly growing newborn at home, or on LinkedIn. Thanks for sharing. We’re excited to see what you continue to build at Herald and the teams & companies you continue to impact in the years ahead!