How to Drive Change Beyond Your Role

The other day I had a good discussion with a developer who’s ambitiously assuming more and more technical leadership roles. When I asked if there’s anything he’s struggling with currently, he mentioned that he sees a lot of processes and practices that he believes could be improved, but doesn’t know how to approach an initiative like this when it’s not explicitly his job to change stuff. We discussed the role of personal and environmental aspects in this situation and found a few things he should be aware of to be more confident in pushing for changes. I kept thinking about this after the call and organized my thoughts on the topic in this article.

Personal aspects

• Trust yourself. The biggest holding-back force is usually self-doubt, low self-confidence, or even impostor syndrome. “Who am I to make this change?”, “What if I’m wrong?”, etc. If you frame your initiative as an experiment and focus on the learning aspect, you can make this voice in your head that makes you doubt yourself shut up. If you embrace the experiment, then even a failure is a win, because both you and the organization learned something useful. Besides, everyone makes mistakes — if someone seemingly doesn’t, it means they don’t take enough risks.
• Choose one thing. There are so many things to improve, it’s hard to focus. If you get overwhelmed by all the changes you could make, you won’t progress on any of them. Select just one, single issue, and focus on improving that. It’s going to be hard because you don’t know in advance what could have the biggest impact, and everything seems promising. It helps to realize that consciously improving one process, even if it turns out to be not the most impactful one, is better than making ad-hoc little changes to multiple things without planning and reflection. The former is a clear experiment with measured results, the latter will most probably just increase change anxiety.
• Have a plan. Once you isolate the one thing you want to improve, make it a proper project even if it’s a smaller thing. Think in writing: Capture the problem; find some metrics you can use to assess the current situation and monitor its change; list different options you think could impact this metric; select one or two you want to try; plan a rollout schedule for the change and how to assess its success or failure.
  It doesn’t need to be very complex, even a simple change like “let’s do async standups twice a week” would benefit from this way of thinking: what exactly are you trying to solve and why, what metrics (qualitative is fine too!) you choose to measure success and avoid regressions, and how you plan to try this out. In the example above, it could be simple like “Context switches on deep focus days are distracting, for the next 2 sprints let’s try switching standups to async on those days. We can monitor the results during the team retrospective - paying attention to developer satisfaction and ensuring no miscommunication happens because of the lack of live sync. Also, watch out for engagement, ensure people don't get lonely.”
• Involve others. Just because a process doesn’t make sense to you, there might be valid reasons why it’s set up like that. Discuss and validate your observations with your peers and manager — this will help get their support too once you decide you have an improvement idea to try. Bounce early ideas off of people informally to test the validity of your problem assessment and potential solutions. The deeper and earlier context they have, even more, the more involved they are in the plan will not just help implement the change but increase its success chances too. (See a personal story on "the IKEA effect" from Jeremy Brown.)
• Share early and frequently. Relatedly, you’ll have more chances to adapt and improve if you show what you plan at various readiness stages. Dumping a nicely polished, finished document on your manager’s desk will counterintuitively make it harder to get feedback on and eventually implement – if you even get to that stage.

I made this mistake early in my career, when working for an ISP as a project manager. I came up with the idea of a micropayment system for monetizing online content, using pre-paid cards from brick and mortar partners. This was the late nineties, so the alternatives were premium rate SMSes or card payments, both with a huge cost overhead that wouldn't have made sense for micropayments. I told myself “This is such a good idea, let me work out all the details before telling anyone so management will be super impressed! I don’t want them to find any fallacies in my masterplan!”. So I worked on evenings and weekends, alone, and after a few weeks, had the — what I thought — perfect 20-something page document describing all the implementation details of my proposal. I gave it to my manager, who was very polite and said something like “very interesting, I’ll take a look”, and then — nothing. My frustration grew, so I asked after a few days, we scheduled a discussion, where he explained that while the idea is interesting, the costs of creating a secure system of prepaid cards, contracts with vendors, compliance and regulatory approvals, etc. could not justify the risk this means for an ISP whose core business is far from monetizing online content. I was bummed, but I understood, it made sense. More importantly, I realized the main lesson: it doesn’t matter if he was right or wrong. What matters is that we should’ve had this discussion before I spent days working on something based on my wrong assumptions.

• Be accountable. Make it clear that you’re not just complaining about something that could be better, not just proposing ideas for change, but you take the ownership to run with this from beginning to end. Take accountability, go further than pointing out the problem, find a solution and implement it. Even if your actions end up not having the results you hoped for, it’s much better to have the image of a doer.
• Communicate intent. If you ask permission to change something from your manager, you imply that she'll have to make this decision and take all the consequences alone. Yet, they don’t have as much context as you do, so she'll either ask questions that push the responsibility back to you or make a guess based on how much they trust you. If you want to show accountability, communicate intent instead of asking for permission. “I’m planning an experiment to improve our team’s Pull Request processes”, or “2 weeks from now we’ll try to address a few tickets in the sprint with pair programming”. This way of communication shows confidence and accountability while giving a chance for your manager to intervene if she hates what you’re about to do.

Environmental aspects

This is for managers, you can do a lot to shape the environment to encourage innovation and bottom-up initiatives in your organizations. A few ideas:

• Build a culture that celebrates failure. I like to over-index and not just say “This is a safe-to-fail environment”, because I want people to work hard on focusing the learnings and growth in failures. The expression “celebrating failures” implies an activity, something that you do when you fail — a “safe-to-fail environment” feels passive to me. (Note that this is personal, and can be risky in underperforming organizations, especially if it’s not paired with accountability.)
• Frame projects as experiments. Don’t require your teams to bet everything on the outcome of their actions, coach them instead to build experiments and take calculated risks. Otherwise, you risk building decision paralysis, overcautiousness, and too much time spent planning.
• Be comfortable with being seen as vulnerable. Model the behavior you want to see: don’t hide your mistakes, to the contrary, be explicit and proactive in talking about them. Give and ask for feedback, show how to take it, and how to adapt your plans based on them. Share what you’ve learned.
• Build leaders at every level. This is one of the main concepts of David Marquet’s inspiring book Turn the Ship Around. People who are running the processes, working with the code, deploying the applications, etc. have the most detailed local context and know best what’s working and what’s not. Be a partner in the intent-based communication explained above. Give your team the freedom to find and execute improvements instead of telling them what to do. This will get them used to a high level of autonomy, and as a result, their engagement and motivation will grow, and they will make better decisions. All these will result in improved team performance.

I write about Engineering Leadership topics similar to this one. Sign up here to receive my future articles by email.