TOC
Driving Abstract Change is Hard
There have been many times in my career where someone has complained to me about the current situation in their company, org, team, project, etc., and despite the fact that they are generally a hard-working, creative ass-kicker, they seem to be stuck playing the victim, cycling on how the situation is somewhere in the range of [sub-optimal, frigging terrible] and not DOING anything about it.
How is that possible? Are they just having a rough day? Or maybe it’s just a numbers game and you’re bound to get a stumper every once in a while?
I don’t think so. There are almost always two common threads in these situations. The victims are often individual contributors (especially engineers), and the problems usually revolve around needing to drive what I’m going to call abstract change - the sort of change that is often only defined as a conceptual, subjective target state; has no deterministic solution, obvious path forward, or even straightforward quantitive measurement; and usually centers around humans and our interactions. For example, how do you change a company’s culture, how do you increase a team’s velocity, or how do you improve a person’s morale?
Why is this so hard? My take is that:
- Driving abstract change can feel very foreign and intractable to people who primarily work on problems with (mostly) deterministic solutions (e.g. engineers). We analyze requirements, consider constraints, and then put together a plan that we know with high probability will meet those requirements within those constraints. Some problems are open-ended or unstructured enough that the initial discovery phase may take some time, or the solution may require some iteration, but it still feels deterministic.
- Driving abstract change often operates at a BIG scale. Like “how do I make collaboration more effective across my 500 person org” big. It’s easy to get overwhelmed by problems of that magnitude and either explicitly give up or just implicitly avoid them.
- Driving abstract change is often fraught with interpersonal risks like stepping on people’s toes, forcing people to do things they’ll resent, or making yourself vulnerable to public failure (see Caveats below).
Put all three together, and even managers, whose entire existence basically centers around driving results non-deterministically through their reports, sometimes still balk at driving abstract change. So what the hell do you do?
Product Market Fit is Actually a Pretty Great Analogy
The answer I’ve come up with for myself is pretty simple: just brainstorm a round of concrete things that might drive the change, DO THEM, learn from the results, and then start over.
Sound familiar? It should - it sounds a lot like a product team doing validated learning to creatively experiment and find product/market fit (or like a SCRUM team doing regular sprint retros). You have no idea what will click with users or drive metrics, so you just keep making informed, strategic guesses and trying stuff until it works (with a healthy feedback loop of measurement, observation, learning, and course correction along the way). Measurement can be harder for human-centric abstract change because sometimes objective metrics just don’t make sense and you instead have to make emotional or intuitive measurements, and in some cases the iteration time is long because people react and internalize change slowly, but otherwise a lot of the same principles hold.
I imagine a lot folks reading this are now rolling their eyes and saying “Well come on, all you’re saying is that in order to drive change, you try things. No freaking duh, everyone does that naturally.” And yet, time and again I have seen people and organizations that don’t do that, where getting people to just do anything can be surprisingly hard. And second, while it’s true that there are some people for whom this sort of experimentation is an instinctive behavior, I think explicitly and deliberately assuming a mentality of continuous concrete change and experimentation to drive abstract change has the following benefits:
- The activation energy becomes extremely low, so you are more likely to take action. You don’t have to come up with a “solution”, nor perfectly constructed experiments. You just have to come up with a change, any change that you think could make a difference, and then do it. Obviously you have to be a little thoughtful if the change is costly, but many aren’t.
- Because of this, you end up trying a much higher volume of things, which increases the likelihood of success.
- The two points above create an immensely empowering morale feedback loop. Instead of feeling overwhelmed or victimized by an impossible problem, you immediately feel like you are making a difference and working towards a solution. And as soon as some of your attempts start paying off, it’s incredibly fulfilling and spurs you on further.
- The process is entirely democratic. You don’t have to be a manager or a leader or otherwise be in a position of power to try stuff. Anyone can come up with large or small ideas that could drive change. A month after I started my last job, before I was a tech lead, had a charter, or was even working on my first major project, I was contributing to our service ecosystem to increase system reliability and piloting our first hackathon in an attempt to increase engineer morale and drive product-centric thinking and innovation. And it doesn’t need to be just you. Brainstorming and acting on ideas as a team or with your work buddies can be fun, effective, and great team-building.
- Because all of your efforts are explicit and deliberately trying to drive certain goals, it’s extremely obvious that you need to spend time learning from them. I think a lot of leaders and managers work intuitively and implicitly, doing all sorts of helpful things all the time without thinking about it much. But if you don’t think about your efforts much, then you often don’t reflect on what works, what doesn’t, and how to further improve (you learn at the speed of your subconscious, which is usually slower than your subconscious and conscious combined).
Examples
I’ve been taking this approach to driving abstract change personally and with my teams since I started my previous job. I can rattle off a ton of things I’ve tried across a bunch of different goals. I think it has made me happier, more effective, and is likely the only way I was able to ramp up on being an effective manager as quickly as I did. Here are some examples from my last few years:
- Pilot a company hackathon program to spur creativity and excitement
- Overhaul the backend eng interview panel to raise our talent bar
- Regularly ask “hard questions” at company all-hands to promote candid communication
- Introduce a “debug of the week” session to help teach debugging and site-up skills
- Introduce a “client support on-call” rotation to decrease the impact of team interrupts
- Overhaul a design review process to increase cross-team alignment, decrease estimation risk, and increase system reliability
- Iterate on a post-mortem process to extract more root cause and increase reliability
- Prioritize auto-generated API documentation to improve client experience
- Build a monitoring-as-code framework to decrease cost of monitoring and increase reliability
- Drive a rationalization of our backend tech stack choice to focus new grassroots investment
- Document legacy systems and architecture to increase cross-team awareness and empathy
- Prioritize projects that require collaboration across teams to build organizational strength
- Introduce regular team retro meetings to drive reflection and self-improvement
- Iterate on a quarterly planning process to increase cross-project awareness and decrease estimation and capacity risk
- See my post on Human Leadership for more examples of the sorts of things managers do for individuals all the time
Caveat #1: But People Hate Churn!
The biggest push-back I get when I describe this perspective to certain leaders is the idea that people inherently hate change, that experimenting with anything human comes at great cost, and that therefore you need to be much more slow and cautiously thoughtful, rather than fast and experimental. While I agree that this principle sometimes holds to some extent (yes, if you were to pull a re-org every 3 months, everyone would hate you), I think human change is often less costly than people think. Especially if an expectation (and preferably culture of) experimentation and improvement is set upfront. Most humans I’ve met prefer to know that leadership or their peers or they themselves are doing something, even if it might not work the first time around, than feel like people aren’t even trying.
And let’s be clear, what are your alternatives? Either you end up in analysis-paralysis and do nothing, or some never-ending committee1 gets formed and ends up spending six months putting together a perfect plan that still only has a 30% chance of success because hey, this is non-deterministic stuff. Except now you’ve only tried one thing in six months and everyone’s expectations are set super high. It doesn’t work for the same reason giant waterfall SDLCs don’t work. Now, I’m not saying that you should just flail wildly such that everyone is exhausted and no one can read any signal from the noise, but there is a pretty large space between chaos and not taking enough action.
Caveat #2: But It Must Be For A Reason!
Another big implicit push-back that I see people (especially junior folks) making without even realizing it is assuming that the “way things are” is for a good reason. There is often a fear that experimentation could only make things worse since “someone smarter than me” must have already optimized everything, or that you might step on somebody’s toes or be punished for “rocking the boat”.
In my experience, this is almost never the case on either front. Most aspects of software systems and organizations haven’t been optimized at all, and even if they have, they don’t stay that way for long. We’re generally all extremely busy folks with many competing priorities operating in a constantly changing environment. There is ALWAYS room for improvement. And almost all senior engineers I’ve met across both IC and manager tracks are delighted when someone wants to make that improvement and has concrete ideas on how to do it (especially if I worked on it last and always wanted to make it just a little… bit… better).
Now, I’m not saying that you won’t sometimes hit friction. Your manager may point to competing priorities, or an old-timer may point out how the status quo actually is optimal for non-obvious reasons, or someone might feel like you are encroaching on their territory. But as long as you go into those conversations with an open mind and a sense of empathy, they are usually a positive experience. And if you DO get shut down or start hitting politicial/turf war issues over and over, escalate to your manager or HR. Companies that stifle grassroots contributions aren’t good companies to work for.
Caveat #3: Top-Down Changes
One of the best aspects of this approach to driving change is how democratic it is, but what about changes that can’t be driven bottoms-up? For example, when change requires re-organization or cross-team commitment, it can be really hard to drive things in a grassroots way. When I’ve run into this problem, I just zoom out one level. Instead of brainstorming ways to drive change, I brainstorm ways to convince leadership to drive change. It’s even less deterministic, but I’ve definitely had some success.
Moving Forward
I hope that this post leaves you feeling excited. Regardless of whether the above is totally new to you, old hat, or anywhere in between, I hope that you’re excited to try some stuff, excited to drive some change, and depending on where you were at, maybe even just excited not to feel powerless anymore. It’s no fun (or good business to be) feeling like a victim to an impossible situation or like you’re stuck in a company or team that never gets any better. And don’t just keep that excitement to yourself. Whenever you hear an “ugh, X sucks” conversation without a “let’s try Y to fix it” follow-up, treat it as an opportunity. I’ve literally just grabbed people into a room and said “OK, let’s try and think of 2 things RIGHT NOW that could help” and then asked them to bring it up at their next team retro. Sometimes it yields immediate results, sometimes it just changes their frame of mind moving forward, but it’s never hurt.
So don’t be intimidated by gnarly, daunting, abstract change! If you want something about your company, team, or projects to be different, just come up with an idea or two and do something about it :)
-
FWIW, it is my strong belief that appointing a committee or working group without a deadline is just a leader’s way of pretending they care about something they don’t have time or energy to think about. ↩︎
New to Two Ways to Learn? Welcome! Check out the manifesto, enjoy some more posts, and share them if you like! As always, I love questions, feedback, discussion, and requests for follow-up details or examples. Leave a comment, tweet at me, or send me an email!
