Read on Twitter
One way to boost your productivity.
Find out who are the “
anti progress” individuals in your org.
Find out who are the “
anti progress” individuals in your org.
Anti progress individuals will resist change at all costs.
Why are some people anti progress?
- they have legitimate fears. They’ve been burned way too many times.
- they don’t like change. “That’s not how we do things here”.
Why are some people anti progress?
- they have legitimate fears. They’ve been burned way too many times.
- they don’t like change. “That’s not how we do things here”.
Most people have good intentions. And sometimes all they need is a nudge in the right direction.
Here’s how you can help them (and your org)
Here’s how you can help them (and your org)
Understand their fears.
- have them been blocked by other people before?
- are they inherently risk averse?
- are their tools and processes not sufficient?
- what do they stand to gain by keeping the status quo?
- have them been blocked by other people before?
- are they inherently risk averse?
- are their tools and processes not sufficient?
- what do they stand to gain by keeping the status quo?
Understand their incentives.
are they (or their org) incentivized to keep things the same?
“You can’t introduce bugs, downtime, or security vulns if you can’t write new code”.
This may be a more systemic issue. But it’s worth understanding what makes an org tick.
are they (or their org) incentivized to keep things the same?
“You can’t introduce bugs, downtime, or security vulns if you can’t write new code”.
This may be a more systemic issue. But it’s worth understanding what makes an org tick.
How did they get in the position they are
Have they (or their org) been given an outsized role or responsibility in reaction to an incident or black swan event?
eg a team gets excessive leverage after an audit, incident, or a big contract
The Phoenix project explores this well
Have they (or their org) been given an outsized role or responsibility in reaction to an incident or black swan event?
eg a team gets excessive leverage after an audit, incident, or a big contract
The Phoenix project explores this well
Learn how to influence them.
Once you do some research to understand why, when, and how someone (or an org) became “anti progress”, you can start taking action.
A few ideas
Once you do some research to understand why, when, and how someone (or an org) became “anti progress”, you can start taking action.
A few ideas
Engage pro-progress partners and sponsors.
You can find others in the org who are willing to sponsor or back your efforts to introduce change.
An executive, a peer, or anyone else who’s also incentivized to see more progress.
You can find others in the org who are willing to sponsor or back your efforts to introduce change.
An executive, a peer, or anyone else who’s also incentivized to see more progress.
Build prototypes that *prove* that certain changes/improvements are possible.
e.g: streamline a build process, try a new tool in a sandbox, make some charts.
It’s very hard to say no to tangible things that have already been built.
e.g: streamline a build process, try a new tool in a sandbox, make some charts.
It’s very hard to say no to tangible things that have already been built.
Write down your proposals and thoughts on the matter, and get to evangelizing.
Write stuff down and get it in front of others. You’ll probably have some 100 eyes in your doc before you realize it.
Worst case scenario: people will respect you for trying, you’ll also get feedback
Write stuff down and get it in front of others. You’ll probably have some 100 eyes in your doc before you realize it.
Worst case scenario: people will respect you for trying, you’ll also get feedback
Find 80/20 solutions to your problem.
It’s possible that some process/system is optimized for the wrong part of the 80/20 spectrum.
Find ways to de-couple your use case...
It’s possible that some process/system is optimized for the wrong part of the 80/20 spectrum.
Find ways to de-couple your use case...
De-coupling part 2:
e.g. I worked in a codebase where 80% of CI time was spent on some 20% backend code that rarely changed.
Solution: we reduced our CI time for frontend code from 45 minutes to 4 minutes by splitting the codebase into a FE and BE one.
e.g. I worked in a codebase where 80% of CI time was spent on some 20% backend code that rarely changed.
Solution: we reduced our CI time for frontend code from 45 minutes to 4 minutes by splitting the codebase into a FE and BE one.
When all else fails, and you’ve *honestly tried your best*:
Find ways to work around the anti-progresses.
- Find someone else to review your code
- Find a sponsor who can override anti-progresses
- Ask for forgiveness, not permission
- Give up
- Go work for someone else
Find ways to work around the anti-progresses.
- Find someone else to review your code
- Find a sponsor who can override anti-progresses
- Ask for forgiveness, not permission
- Give up
- Go work for someone else
