My company got acquired! Now what?

So you've been working on this product, got something interesting, probably even some customers, and a larger company got interested in the product enough to acquire the company (some of this advice also applies if they were interested in the people or something else other than the existing product, but I'm mostly writing here about the case where - at least supposedly - the intention is to keep and grow the product you were working on before the acquisition).

Some of the following is broken down by function but even more than usual this is a case where it pays to have some cross functional awareness of what is happening even if you are responsible for one of these areas more than others.

First of all, you are now part of a much bigger company. Therefore, a lot of the challenges are communication ones. There's a whole set of issues around getting to know people in disparate parts of the organization, setting expectations, self promotion, and probably a bunch I'm forgetting to call out specifically. But many of them change and get more important at a bigger company.

An acquisition tends to bring up a lot of feelings - for example excitement, accomplishment, sadness, and disorientation. Particularly for people managers, but also everyone, a lot of the job is talking people - including yourself - down from various ledges and getting information about benefits, offices (and/or remote practices), org charts, company strategy, and more. Basically to make sure people know what is going on, have input as feasible, and that things like 1:1s are doing the job of getting into issues which might be less amenable to blanket emails and the like.

For product, the key challenge is "are we working on what the higher ups acquired this product for?" But before even getting to that, regularly ask a more basic question: "Do people widely understand our product (existing and future functionality)?" The big company adage is "err on the side of overcommunicating" and my experience is that you need a lot of different ways to even get to a shared baseline of what we have today (for example, via demo days, screenshots, getting people internally to try the product, and bringing in customer input). Many of the same mechanisms also apply to a shared understanding of what we want to build next and why.

For technical issues, how does the other company handle deployment? Security? Programming languages? Testing? How much do we expect to standardize and how much do we expect to remain divergent? If we want to converge, what do we tackle first and how?

Culturally, the number one thing I'd focus on is how to have contact with people who had been from the other company. Maybe there are interest groups around hobbies, diversity, or charitable activities. Or more work-related things like "people using a common programming language", "people interested in security", or other concerns which may cut across the org chart. It can be easy to neglect things which aren't tied to a concrete deliverable, but the goal here is to build relationships. It is so much easier to navigate an unfamiliar organization and solve a tough problem if you know people and understand assumptions or typical ways of approaching things.

Will you stay with a company for long after acquisition? Does a product have a good change of thriving after acquisition? I'm not diving deeply into that, and there is no shame if the company you end up leaving in a few (months, years, whatever) just doesn't feel like the one you worked for pre-acquisition. But here I try to present the optimistic case for how you can jump into tackling a work situation which just changed (perhaps very dramatically) when your company was acquired.

The Mortifying Ordeal of Soloing All Day

I read The Mortifying Ordeal of Pairing All Day by Nat Bennett, and.... well first of all it is a good read and worth trying to take in. Perhaps the best way to respond with such a heartfelt and personal story is with my own story. Maybe some day I'll find another way to tell it, but it rang surprisingly true to just take that article and instead lightly edit it to be about my own struggles with soloing (including in many companies where pairing had once been a norm but then fell away for various reasons). The result takes a few liberties here and there but is on the whole autobiographical.

The Mortifying Ordeal of Soloing All Day

I had to confront a lot of my fears about myself, sometimes every day. I had to learn to show someone else all the things I didn’t know, my limitations as a human and a software engineer.

From 2014 to 2020 I was part of an experiment: I soloed all day, most days, for years. Hundreds of other engineers joined me in this experiment. I was working as a software engineer for some of Tech's most exciting startups, and everyone soloed, often for eight hours a day.

This was one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software. It also burned me out. Not “I don’t want to think about work” burnout. Probably not even “I don’t want to work ever again” burnout. Whether "burnout" is even the exact best word is unclear, but it is close enough to describe a situation where I was often worrying about work (not sleeping well for example).

I spent much of 2020 in discussions with management about how I was doing which led to leaving my job in May 2021 with no plan much more concrete than "give myself and the world a few months to breathe". I'm still recovering to the point of being able to set goals for a job search (or other plan for the future).

I also believe that the expectation that everyone solo, all the time, led to technical and product failures at multiple companies.

There’s a response I often get at this point, especially from people who were managers in the organization at the time:

“But Jim, teams weren’t expected to solo all the time. You might have been assigned tasks, but you were given leeway to accomplish those how you wanted, and management didn’t require people to solo all the time. If a team wanted to solo less, they could.”

This is true. Engineers and teams had a lot more freedom than they realized they had. I spent a lot of my time there helping people realize that. I would often spend one or two days a week pairing for at least part of the day.

And yet.

Engineers had individual laptops and sometimes set up them according to individual preferences.

We were Tech Company Engineers, and one of the things that made us Tech Company Engineers was that we soloed.

One of the great and terrible things about Tech, is that it operationalizes peer pressure. It harnesses drives that humans have, drives for identity and belonging, in the service of producing software. These forces were only tenuously under management control.

So I soloed all day, most days, for about five years. This had a lot of upsides, far more than I can list here. Soloing really develops being able to plan out and execute a task, giving yourself time to think through a problem, understanding the technologies you are using, and developing proficiency which might not happen if you are leaning on your pair (sometimes more than you realize). The impact of soloing, especially soloing that much, goes much deeper than its impact on the code, on the particular work the team delivers that week.

(Here would go an anecdote about how people who solo have self confidence and mastery.... sorry I'm not thinking of an immediate analogue to the Overcooked example in the original article).

We take the time to understand a problem so we can make informed decisions.

This is the real power of soloing, intense soloing. Understanding what you’re doing, and adjusting it based on further research or the results of experiments, becomes automatic. For someone who thrived on pairing and loved it when there was a strong team spirit, this was an almost psychedelic experience. I transcended the limitations of the people I was working with and discovered that I was able to accomplish things.

I remember once, looking over a large office filled with people working at workstations, and thinking, “This is the most talented collection of people I have ever seen in one space.” I understand why engineers so fiercely defend their right to hack.

But: cognitive impairment.

Months where I struggled to meet my own basic needs.

Soloing requires putting up a facade of self-sufficiency, to management and the rest of the organization, for hours at a time. Being able to manage oneself, both physically and mentally. I had to manage my space, my decisions, my thought processes, and often my feelings on my own.

This never stopped being draining. Even with an easy team, where I had clear goals and could accomplish things without effort, soloing well requires staying engaged with my environment, with what I'm supposed to be doing. No retreating into sensory experiences, no checking my phone, no wandering off or getting distracted. Maintaining that level of focus for hours at at time was thrilling, but it also required a serious exercise of will.

There were some teams where it required more than will. I had to fight to stay engaged. I had to develop skills. There were people with whom I disagreed, but with whom I struggled to resolve those agreements. There were people who didn’t put nearly as much thought into my experience as I was putting into theirs. There were people who expected me to “just make it work”, despite an ill-defined and not-yet implemented interface that I was expected to use. There were people who just made me anxious or uncomfortable.

I had to confront a lot of my fears about myself. I had to learn to show someone else what I could and could not do, my limitations as a human and a software engineer.

Over time, over years, soloing wore me down. Took a little bit more each day than I could recover. Until my life was working, and recovering from work, and then working some more.

And then the pandemic happened. Overnight, suddenly, I was performing this daily act of will without the support of the office, without going out to lunch at my favorite restaurant, without anyone to talk to except in scheduled meetings, while the world burned down around me.

I crumpled. I stopped being able to solo. Stopped being able to have a conversation.

This wasn’t everyone’s experience with soloing. In a two-by-two grid where one axis is “sensitive to the demands of soloing” and the other is “time committed to soloing” I’m hugging the upper left hand corner. My experience was extreme.

And yet.

Tech companies, I’m told, have reputations as “burnout factories.” Many people left my companies, at least a few of them to escape from the demands of daily soloing. People who love soloing, who see the benefit of it, but who despite all those benefits are tired.

There are people who can solo indefinitely, for years. Who don’t experience the most demanding version of it often. Whose recovery capacity comfortably outpaces the demand. A lot of those people, at most tech companies, end up in management roles, in leadership roles, and then they miss coding. Many places I've worked have had a leadership staff that, even when they believed me when about how demanding soloing was for me, couldn’t really see it themselves. Some of them even tried to find ways to enable me to solo less, but I'm not sure they understood all the forces which were making it hard to do anything but solo.

We’ve all heard the bad reasons not to solo. "You are just cowboy coding." "You can't think about anyone other than yourself and your pet project." "You don't care about doing things well."

I’ve dismissed people making those arguments as fundamentally dogmatic, unwilling to do the hard work of real software development.

Now, though, I hear those objections, and I hear fear. A fear that I share. A fear of exposing my vulnerability, my ignorance, my soft parts, and a fear of the cost of that exposure, of the cost to my mind and my body of subjecting myself to that exposure, day after day, in exchange for a paycheck.

Underneath the urge to dismiss those concerns, I hear another fear. A fear that soloing is too hard, that people wouldn’t choose to do it if they weren’t corralled into it by individual goals and hiring and promotion processes which emphasize "yes, but what did you do personally?". That a “soloing culture” is such a delicate wisp of a thing that if you allowed engineers to solve problems together, they would abandon soloing immediately.

What did we miss out on, by failing to make more space for people not to solo? By treating this soloing culture as something so fragile, and so precious?

Flow

So if you've been around tech, you've probably heard of flow. You know, the state of concentration where you are one with the code, getting stuff done, and the code loves you back. This is also often said to be incredibly fragile: the slightest interruption will cost you 15 minutes, in terms of how long it takes to resume your concentration.

Although I've experienced this enough that I think I understand the process described here, my own experience of flow has much more to do with other people. I use the analogy of improv comedy - I suggest a thing, you say "oh, but what about this other component?", I say "well, let's try an experiment to confirm that idea", you say "ah, and that means we can delete this part of the code" and I say "oh and now that's gone, we can implement this other thing in a more elegant way". If you've heard of the "Yes, And" concept (which originated in improv and has been borrowed to workplaces) this may sound familiar. We're riffing off each other, we're generating ideas and figuring out where to take them, we're bringing in multiple perspectives about what we are trying to accomplish and how we are doing it.

I mentioned this analogy to a co-worker who is a musician in their spare time. And they immediately said "oh yeah, jamming with someone is definitely a thing" (and contrasted it with teaching, which can feel quite different).

Everything so far is based on my own experiences and folk lore within software companies. To write this post, I figured I should at least look a bit at academic or popular writing on flow, which seems to start with psychologist Mihaly Csikszentmihalyi who originated the term in 1975, and proceed to follow-on work in the following decades. Well, I've only read a few short summaries, but what I did surprised me a bit. It didn't neatly fit into the model of flow being all about being solitary and avoiding all interruptions. As far as I can tell it has just as much to do with whether goals are clear, whether the skills needed are within reach (with perhaps a slight stretch), and whether there is immediate feedback. And that flow can be either individual or group. I'd already decided that I didn't need to be threatened by the concept of flow even if it seemed to be promoting a working style which tends not to work well for me. That is, that I could redirect the concept to something which is recognizable but closer to what makes me thrive. It was nice to see that what is written on flow turns out not to be quite as different from my own thinking as I had initially imagined.

The four kinds of developers

I'm probably going to go to hell (or worse yet, business school) for presenting it this way, but developers (or probably more accurately development tasks) fall along two axes:

One axis is gregarious/solitary

One axis is coding/non-coding

• Gregarious+coding: pair programming, code review, group debugging, hackathons
• Gregarious+non-coding: standing around a whiteboard figuring out an architecture, reviewing an incident together, hashing out requirements via discussions
• Solitary+coding: put on those headphones and make the software work. Make it beautiful. Make it sing to me.
• Solitary+non-coding: think hard about some really tricky algorithm. Gather a bunch of written input and write a design document.

Disclaimers:

1. Unlike the classic 2×2 matrix, no quadrant is better than the others. Individual personalities, whether people happen to click, and other factors will push in various directions or towards a mix.
2. This describes various activities on a technical track. I'm not trying to describe management track.