How to turn a team around in one easy step

My last four roles have all been “turn-around” scenarios. At CCP Games I had three: as Technical Art Director, I turned around a group that was struggling on executing basic tooling; as Technical Director I had to turn an entire engineering department that was writing an order of magnitude more lines of code than they should have been; as a Senior Engineer in Atlanta I was to figure out how to ship a game that had been in limbo for 8 years. As the head of engineering at Cozy, I needed to figure out how to rebuild the team and product and grow the business 100 times over without increasing costs. I feel like I have a pretty broad view of the turn-around scenario at a variety of levels of leadership (frontline manager to executive), group size (5-100+), and scope (homogenous team to entire company).

Over the past weeks, I’ve been reflecting on the commonalities between all these turn-around cases, and I think I found it:

Decide what you value, and refuse to compromise on those values.

“Legacy” environments come with a lot of baggage and differing views. My job was not to compromise between these views. My job was to create an environment where people could do their best work, which (to me) required establishing values and rejecting compromises that did not advance those values. Reframing compromise in this way meant that solutions came through a shared understanding based on a shared set of values, not some midway point between what two parties wanted. Folks who had a shared understanding of values, no matter how different their point of view or perspective, came away from discussions happier and with better solutions.

Here are various values I’ve held over the years, what I see as their obvious implications, and views that, no matter how well-meaning, needed to be rejected in order to adhere to those values.

• If we value longevity and career growth, we must hire and support junior developers, and provide an explicit path for people to transfer between departments/roles. We cannot run our customer support organization as a sweatshop because our process or tooling is inefficient. We cannot only hire senior employees because the ramp-up time is shorter.
• If we value high quality, tested code, we need to write tests and refactor. We will slow down to teach inexperienced developers how to write high quality code quickly. We cannot develop a new feature without tests and plan to add them after-the-fact because the feature is “really important.” Expect that we will “waste time” having to stop and fix flaky or confusing tests.
• If we value quickly delivering value, we need to trim and slice large features and focus on building the highest-priority items. We cannot work on big drops of plumbing or feature work, even if it seems convenient at the beginning. We cannot accept that “it’s all important” when identifying what to cut and what to build.
• If we value building a simple, intuitive product we must not hold anything sacred. We may cut a feature even though we just built it and it was expensive. We must add or speed up a feature even though we can’t find a place to put it in our clean technical architecture.
• If we value rapid iteration, we must accept the result. We must not mandate strict manual QA processes just because a bug hit production. We aren’t having design reviews because a screen went out that doesn’t match the comp.
• If we value having great employees, we must treat them as such. Our policies should guide and inspire them, not constrain them. We must never try lie to them, like when we pretend we know what we’re doing though we don’t. We must never insult them, like trying to convince them benefits are part of a ‘total compensation’ when they feel underpaid.
• If we value diversity, we must also value inclusion. We cannot take a white-male-evolved company, sprinkle in some under-represented people, and expect them to get on fine without examining how the core of the company functions. We must accept the validity of all grievances, especially when we don’t understand them.

Debate wasn’t about whether a practice or policy was “good” or “bad” but, did it promote the values we want to promise? Now, you can debate the value itself- do we actually want a company with career growth, or is it a good idea to build things with high quality- but that is a separate debate. I’m happy to engage! I don’t claim that the values I’ve chosen are the right ones, but they are the ones we’re going with until we’re not.

Many of my struggles related to not establishing values clearly enough. Sometimes I wasn’t explicit enough in my realm of authority, which could be resolved. More commonly, I would run up against other managers in the organization who agreed with my values or what I was achieving, but didn’t understand the “lack of compromise” with the existing systems was the only way to achieve those values in that environment. See all the examples above!

Ultimately I don’t believe any of these disagreements were resolvable peer-to-peer. They were inevitable! We couldn’t turn things around in the presence of a shared leader who was unwilling to define, enforce, and demonstrate their values (they were often the reason the turnaround was needed in the first place!). I learned the likelihood of failure early in my career (see my last post), but it didn’t mean I shied away. It just meant that I knew what I was getting into, knew my limits, knew the outcomes. And on the whole, I’m very proud of what I learned and achieved, and left behind positive legacies.

† The First 90 Days is a good book that describes 4 different ‘new leader’ situations. See this slide for a description of each (Start-up, Turn-around, Realignment, Sustaining success).