This content originally appeared on DEV Community and was authored by Ben Link
Let's dust off my crystal ball today. What do I as the writer know about you as the reader?
Well, if you're the kind of dev who's out here avidly reading blogs by other devs like me, it means you're the type of person who checks a few boxes:
- You're interested in technology, mostly software development. (It'd be hard to find this blog otherwise!)
- You're exposed to wide variety of ideas and schools of thought. (I know I'm just one voice of many, even here on DEV.)
- You're interested in growing & improving. (You wouldn't be out here exposing yourself to new ideas otherwise!)
(Hey - I'm right there with ya. Nerds rule the world! 🤓)
I also know that there are a finite number of companies out there. While there are many who are pushing the envelope and working hard to improve developers' career experience, there statistically has to be a significant percentage who aren't. (It's kinda like the George Carlin joke: "Imagine how dumb the average person is. Now realize that half of them are dumber than that!")
So it stands to reason that at some point, you... the technophile developer who's been exposed to a lot of different ideas and is interested in growing and improving... you are going to be in a job where you think something needs to change. Heck, you might be in that job already!
I want to see something change. What do I do now???
Knowing there's a better way is a bit like Pandora's box - once you open up to a new idea, you'll never be able to be at peace knowing that there's a better way and you aren't doing it. So if you've acquired that knowledge already, you really only have two possible courses of action:
Don't try to change it. Just leave.
Oh, Blink, that's kinda harsh, isn't it? Yes, it is. But finding another place to work is definitely an option. You know what to search for now - you know the things that are making you unhappy and you can head out and find a place that matches your beliefs.
In some cases, you might actually find that this is the BEST option. When would that be?
- If Management is entrenched, and you're not part of the 'in' crowd. You know the "good old boys' club" when you see it. There's a group of folks whose careers advanced together and they side with each other in the debates and they've cornered the market on "how we do stuff". Your chances of making significant change in an organization like this are slim. If you were part of the "club" you could use that influence to grow... but if you're not, every. single. step. will be a drag. And their influence will water down the changes you're trying to make, too - you might fight long and hard to implement something, only to have it mangled into something that doesn't actually make life better.
- If Management is toxic. I wish so much that I could convince more people that working under toxic management "just because I'm grateful to have a job" isn't worth it. If you think your management is toxic and you don't have any prospect of joining management yourself to change it, you should be actively pursuing a new opportunity. You don't owe your employer anything other than the time you've agreed to work - get out as fast as you can!
- If You're already on the verge of burnout. Burnout comes in cycles, but the amplitude of the wave increases dramatically once you see a new idea that you can't implement... that is to say your valleys will be much lower, and it will take a longer time and more effort to climb back up to a satisfactory state.
- You don't have other rebels around you. Rebelling against the Empire is tough when you have lots of help; doing it alone is foolish. If you can't build at least a small coalition quickly, it's probably better to just cut your losses and run for the hills.
Become a Change Agent.
If you choose to stick around, you obviously won't be satisfied with the status quo. You're going to need to share your knowledge and help encourage the team to change directions.
...but "Become a Change Agent" is a mouthful. If you're a software developer, it likely wasn't part of any schooling you had. It's not like someone at the company is going to say, "Hey, let's teach you how to convince us that we need to do things differently and then teach you to teach us how to do it!"
So how do you become a change agent?
Change Agents are like the "Special Forces" of IT - they often have minimal support and have to improvise.
Change Agent Skillsets
Technical Acumen. You have to know how to do the work, both the old way AND the new way. It's the only way to get a valid comparison, and it's absolutely necessary that you test your hypothesis rigorously! Be sure you can make the improvement before you try to sell people on the idea.
Communication. You're going to be talking to your fellow engineers. And then to middle management. And then to Architects and the C-Suite. And then to other groups like Security, or Governance/Compliance teams, or Project Managers, or HR, or Legal, or any number of other teams that interface with the processes you're trying to change. You must be comfortable with every one of these conversations, and more importantly, you must make them comfortable with you, too!
Project Management. As a change agent you won't often get "formal" help from the organization. You'll have to manage yourself and keep on task - which means that in order to be effective, you have to have all those organization skills to keep yourself working on the most valuable task at any given time.
Architectural Vision. You need to know what you're trying to change INTO. If you don't have your plan ready, folks will sniff it out early and resist your attempts even more. Note: you don't have to have a meticulous plan in place, but you'd absolutely better have a general outline. What are the big-rock concepts that you're trying to change? What processes are involved, what teams, and how do they have to adjust?
Being a change agent will require you to fully commit.
Organizational change is a difficult proposition, especially if you have to convince everyone that change is needed first. If you're signing up to be a change agent only because you think it's "a nice feather in your cap", beware! You're signing up for a lot of work, and very little reward (most of the time, anyway). You'll be setting yourself up in direct opposition to established practices and habits.
You'll be arguing with people several layers up the organization from you. It's not for the faint of heart!
What Change Agents SHOULDN'T do
1 - Be Unilateral.
The "Engineer Brain" tends to take the shortest path. "Hey, I know how to solve this!" and so you do... and then everyone around you goes berserk because you just unilaterally changed how everything works. If you're not changing together, you can't actually call it "change".
2 - Get Combative.
Another part of the "Engineer Brain" is that we know that we know that we know we're right. We've run the numbers. We've tested. We've implemented it all in our heads and it makes perfect sense. And when someone raises an objection... "how can they be so dumb???"
Yeah. We all think it. Don't say it out loud though! Your default tactics (assuming the role of "expert") won't work!
3 - Insist on Perfection.
You know exactly how you think your change should be implemented. After all, for the last point you ran the numbers and tested and everything.
You're not likely going to get everything just the way you want it. Stop trying to win the whole war in one battle... focus on chipping away at the resistance, taking small wins where you can get them, and gradually move toward the plan in your head. A small rudder turns a big ship, slowly.
What Change Agents SHOULD do
1 - Build Coalitions.
This can be uncomfortable for us - as software engineers, very few of us are highly extroverted. But if you start making friends all across the organization, you'll find it easier to implement changes because you'll have friends in whatever team you need help from. Just as we said you shouldn't be unilateral, you should intentionally widen your circle so that you build good relationships with as many different teams as possible.
2 - Encourage and Cheer on.
While you're on that journey to build coalitions, one way to endear yourself to another team is to help them succeed in something that they'll get the credit for. At the very least, encouraging them and suggesting ways to help them achieve their goals will ingratiate you with them, but if you can go as far as advocating for them, putting in a good word, or pointing them out for something awesome, you'll be sure to make fast friends.
3 - Lead by Example.
I saved this for last because it's my personal favorite. We've all heard the line before: "Be the change you want to see in the world." Well, it's no different as a change agent in an organization! Are you a proponent of Test-Driven Development? Build your app with a suite of unit tests and SHOW people rather than TELL them. Do you think AI is going to be the next Big Thing®? Create stuff with it and demonstrate it to others.
There are acres of armchair quarterbacks in the world. They can all tell you what ought to happen. They can explain the theory and strategy in intricate detail... but the number of people who will get out of the armchair and throw the ball themselves is much, much smaller. If you're looking to change even a mildly resistant organization, you'd better be ready to roll up your sleeves and throw down.
Wrapping up
Knowing that things can be better is the easy part. Convincing a group of people to follow you on some foolish idealistic crusade... well, that's gonna take time, effort, and luck.
You have a choice: take your skills elsewhere and find greener pastures, or step up and work to change the organization. I believe in you! Thoughtfully building a strategy for championing change will help you hold onto your sanity when things are hectic.
I hope you've picked up a couple pointers for leading the charge to make things better for your team... and I hope to see you back here next week as we find some new tech toys to explore! We're going to start a series to build a game together - and pick up some devops and other software engineering principles along the way! See you next time!
This content originally appeared on DEV Community and was authored by Ben Link
Ben Link | Sciencx (2024-07-04T11:00:00+00:00) The Adventures of Blink #30: Change Agents. Retrieved from https://www.scien.cx/2024/07/04/the-adventures-of-blink-30-change-agents/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.