Have you ever watched the final episode of the TV show “Mad Men”? The main character Don Draper, a lion at the top of the advertising industry, sits in on a pitch meeting of the newly merged advertising agency where he still works but once owned. The unquestioningly brilliant archetype sits at a table opposite the faces of the new people he’s supposed to work with, staring blankly at his replacement, and he realizes in an instant that his position of unquestioned dominance has evaporated into thin air. Unable to adapt, he silently stands up and leaves, never to return.

Such is the real world when two companies merge. Some people adapt and thrive, while others simply won’t stick around. I often think about the day, soon after Altos Solutions, where I was a software engineer, was acquired by Flatiron Health, when our group of about ten engineers met, for an all-day introduction to see how this would work. For me, an engineer outside of any leadership position, it was like being in a space ship, floating high above and watching two very different galaxies collide. Would they have enough gravity to constructively merge into something bigger and better?

The Acquisition

Looking back, it seems like ages, but it was only about three and a half years ago. The Altos engineering culture, born out of the aerospace industry, was tightly knit, skewed towards senior-level engineers and had a traditional top-down style of leadership and followership. A few men comprised a club with a highly insular style of decision making. You were either in the club, or a code monkey. Not exactly inspiring, but we did get a lot of stuff done; after all, we did build an EHR that successfully competed in the healthcare market alongside multi-billion dollar companies, obtaining a sizeable chunk of the market.

It was certainly a very tricky exercise in avoiding mass exodus while moving the new engineering group forward into a constructive, new culture. The concept was simple enough. Take this group of small-shop engineers who had been working together for the better part of 10 years, and merge them into a brand new, work-in-progress, enterprise-level culture a la Google or Facebook.

And something amazing happened soon after we merged. The top down model was flipped onto its head. The Altos engineers were quickly but carefully challenged with a steady stream of “why”s. Questions like, “Why did you design this piece like this?” and “Why not make this or that a reusable component?” Simple questions that made for more than a few uncomfortable moments as very different people and attitudes collided.

It went surprisingly well though, and by the end of the first year those who weren’t going to change and grow had left, and the new engineering culture emerged stronger. Today, our culture is based on mutual respect and an assumption of worthiness and intelligence, where the battle of ideas rest upon facts and the quality of an idea itself.

What I Learned

How many of the original engineers have stuck around since the acquisition? Maybe half. As time has passed and our culture has matured, the talent and skill level has only gone up. The line between the old and the new is mostly fuzzy. So what is it about the original Altos engineers that helped them not only survive, but thrive here? And what kind of experiences did the new engineers have that enabled us to successfully merge? Most importantly, what were the key ingredients that worked in mixing the old and the new into a recipe for success?

Here’s what I learned:

Never Confuse Lack of Experience with Lack of Good Judgement
When I talk with engineers who are early in their technical journey, I always try to put myself in their shoes. I’m reminded of what it’s like to have my entire career before me, to be looking at some problem, perhaps having never faced it. It is tempting as a seasoned and grizzled engineer to listen to one’s ego and pride and be unfairly dismissive of a less experienced engineer’s ideas or opinions. But inexperience has nothing to do with intelligence or skill, and a fair-minded person should know this. Watch as you help new engineers learn and become fluent in the products and code that are old hat to you. Let their new ideas and brilliance inspire and motivate you. When you finally have that moment of panic and realize they’re better and faster than you in your old familiar codebase, congratulations Yoda, you just helped create a new Jedi.

Don’t Assume the Experienced are Close Minded
Those of us remaining from Altos and thriving at Flatiron have shown a flexibility and positive attitude about change. Since our first meeting, Flatiron has been on a relentless march to solve some huge technological problems in the healthcare industry. Constant change is part and parcel of that pace of innovation. But resistance may not be about unwanted change, but rather in knowing where a good return can be had on investment of time and energy. There is virtue in leaving something that is working well enough alone, at least until the right time comes along. Knowing when to fish or cut bait is often earned with grey hairs. I am thankful to newer engineers who seek deeper understanding, who always ask why something is the way it is, before suggesting improvements or enhancements.

Work Habits and Styles Change Across Generations
This is a biggie, and something that I never could have imagined at the beginning of my career. The progressive, contemporary culture created at companies like Flatiron simply didn’t exist when the Altos engineers were cutting our teeth in the software business. Everything has changed.

How people work, collaborate and communicate has changed, and I’m not just talking about texting or emailing. For me, this was an even bigger professional change than adapting to new coding platforms, technologies, paradigms and methodologies. Recognizing that different generations work differently – and accepting it – has helped me. This subject could fill an entire book, but let me share what I’ve observed about my newer peers time and again here at Flatiron.

Where engineers from my cohort have traditionally assumed individual contribution of finished project work, newer engineers seem to wisely avoid the risk of individual ownership of work that is large and complex, assuming a more collaborative approach from the start. This collaboration involves constant, often unprompted feedback and opinions, what we at Flatiron call “Give and receive 30% feedback”. In an old-school engineering culture, feedback about unfinished work can often feel like direct criticism of a person’s skills. Flatiron’s engineering culture is much more comfortable with the give and take, possessing a desire to be constructively critical of work so that it might be that much better. As is often the case in life, a little humor (i.e. tons of giphys) goes a long way to smooth over the tiny pain of having your work scrutinized. I’m still pleasantly taken aback by the politeness, directness, optimism and fastidiousness of my Flatiron peers. This is a big deal.

In the End

The engineering merge was quite an experience, though I’d say ours was about as pain-free as possible. Honestly, the reason I think it was successful is because of a specific Flatiron core value that early on, people exemplified time and again during some tense moments; “Be Kind.” I watched many first-time Flatiron leaders exhibit unflappable kindness and refreshing maturity during some heated exchanges with people who were unwilling to change. Kindness along with calm persistence got us through every disagreement and won the day.

Here we are a couple years later. Flatiron has around 450 people, with about 150 engineers and technologists. The galactic merge is just a whisper of a memory, but with a great lesson to share. The divisions are gone. The old attitudes are gone. Our flagship product, OncoEMR®, serves more than double the number of physicians, nurses and practice administrators compared to only a couple of years ago. We’re taking core products that each culture created to improve cancer patients’ chances of survival, and shooting for the moon everyday.

Author
Software Engineer
A 20-year Microsoft stack software engineer, Patrick is life-long, visual learner with way too many hobbies and a renewed excitement for front-end UX frameworks like React/Redux.
Back