Software Engineering Grief
Change is inevitable, especially in software engineering. If you're not driving change, how do you respond when change is foisted upon you?
Join the DZone community and get the full member experience.
Join For FreeHuman beings resist change. This is not personal opinion, it's our defense mechanism against uncertainty. If you narrow your target to software engineers and technologists - who, in almost all cases, are humans - the defense mechanism can become a survival mechanism.
Successful companies rarely rest on their laurels and assume the money will flow in unimpeded by change. Instead, companies constantly analyze the current to define their vision for the future:
How do economic and market conditions affect our ability to sell?
Would new features or product offerings attract new customers while retaining existing customers?
Could we more efficiently increase market share through acquisitions rather than internal product development?
Are there partner opportunities beneficial to us?
How can we expand the industries in which are products are sold?
And on and on and on. Answering the questions leads to decisions about company direction, which leads to change: a fast-growing product gets additional resources while a stagnant product is starved or even killed; a nascent market receives R&D funding while expanding an existing market does not. Decisions made well above my pay grade, decisions which make or break senior leaders. Regardless, change is constant.
Change is the one constant in software engineering: programming languages, tech stacks, database types, deployment models, user interfaces, integration patterns, security requirements, processes, and methodology. What else has changed in your technology career? Eventually, your day-to-day work is affected, and then what? You're human, so of course you push back.
While change may be better for all involved, rarely does it go smoothly.
Stages
1. Disregard
Anyone who has written software professionally for a reasonable period has likely suffered through experienced at least one change cycle which may impact how software solutions are designed and implemented. Some are good changes, some are bad, but you don't know about this one.
It often starts as vague rumors and whispers in the wind that something is being discussed, rumors that may disappear as fast as they appeared in the first place. You hope assume that the talk is a scuttlebutt that, for now, is not worth wasting the mental effort to worry about it - especially if you can't control it - so you decide to keep your head down and continue work on your current assignments. It can't exist if you ignore it, right?
2. Deny
The rumors continue and intensify, acquiring a level of specificity that makes the rumors more tangible than your run-of-the-mill rumor, and definitely more tangible than you want to admit. You comfort yourself by believing it won't impact you, your product, or your deliverables because, of course, you're not the one spreading the rumors. It's Team X's fault, why did they make that promise?!? You continue to keep your head down and work on your current assignments, having created your stock answers to reduce the chatter. . . assuming anyone's interested in your opinion in the first place.
3. Be Angry
The rumors can no longer be denied, and, in fact, directly impact you: your product, your technology, your design, your processes, whatever. It's become personal and you've become the senior citizens admonishing teenagers to get off your lawn: I've been writing software this way for 200 years and you can't make me change! Unfortunately for you, they can make changes without your agreement, understanding, or approval. You either accept that change is occurring or get shown the door. You're boxed into a corner, making you more angry.
4. Negotiate
After further discussions and exploration, you've finally admitted - to yourself, your peers, and your leadership - that something's going to change. As now is not the time to change employers, you become negotiator-in-chief, attempting to mitigate the overall impact or, more importantly, the overall impact on you.
Your first concession is to accept change to the low-hanging fruit and anything else you find uninteresting, making it appear you're on board. Next, you'll offer alternatives to the most onerous or disagreeable (to you) changes in an attempt to soften the impact (to you). Though others may believe you are on board, you are, in fact, probing to see where you're able to influence the decisions into something more agreeable (to you).
5. Accept Change
Despite your best efforts to soften the changes, you've lost the battle. Even worse, the final agreed-upon changes are even more pervasive and intrusive than feared, and your day-to-day work is substantially changing with a likely impact on your productivity. This does not imply that you're happy about it, but leadership has the petal-to-the-metal and your ride is just beginning. Bummed, but life goes on.
6. Internalize
It's time to take a deep breath and move on. You incorporate the change into your daily work, you start to understand and admit the benefits. Publicly you haven't conceded that change was necessary - it's still possible that someone will see the errors in their ways - but you are looking forward and no longer reminiscing nostalgically about how things were. It's time to become part of the solution instead of being the problem child.
7. Advocate
Over a period of time - weeks or months, sprints or releases - you finally grok the overall benefits to your organization. Not only are you on board, but you are key to explaining and promoting the benefits to your team and anyone else who will listen. New products, faster time-to-market, increased code quality, fewer customer support issues, better data, and in general, a reimagined organization. You no longer think about what you're doing or why, it just is . . . ideal until the next change cycle!
So Now What?
Many of you have experienced at least some levels of grief when your organization proposes a change that appears to be unnecessary, non-sensical, out-of-character, or just outright wrong, but nothing apparently can cause leadership to pause and reconsider. The decision has been made: go forward and execute. I've been there more times than I'd like to admit.
As your career advances, as you are better able to present counterarguments to the proposed changes, you may be able to at least somewhat adjust how the changes impact the engineering staff. That said, some decisions are immutable, no matter how bad they appear to the minions. The only choice is to become a senior leader and have a (remote) seat at the table. And even then, your influence might be negligible.
The choices of last resort are either to shut-the-fuck-up or find a new job.
Image Credits
- "Grief-2.jpg" by docoverachiever is licensed under CC BY 2.0.
- "Mutual disregard" by thriddle is licensed under CC BY-NC-SA 2.0.
- "denial" by robynejay is licensed under CC BY-SA 2.0.
- "facial expression - anger" by DesignFathoms is licensed under CC BY-NC-SA 2.0.
- "PATHWAYS Negotiation Education Summer2018" by U.S. Embassy Jerusalem is licensed under CC BY 2.0.
- "202 - Accepted" by GirlieMac is licensed under CC BY 2.0.
- "Free Hugs Campaign International" by Juan Mann is licensed under CC BY-NC-ND 2.0.
- "Education Advocate Malala Attends MDG Event" by United Nations Photo is licensed under CC BY-NC-ND 2.0.
Published at DZone with permission of Scott Sosna. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments