I failed to convince the people I work with to embrace change, so I resigned
Sharing a view into a software architect’s work and how I failed to convince people that change is good, which led me to leave the company.
So what exactly happened?
I started as a developer (later architect) at a medium sized enterprise which had it’s own flagship product. The job mainly focused on developing this product. The domain we worked on was pretty big (finance).
Now, the product had history. Years worth. And like with any software that has a long history, it has technical debt. But what it was also missing was technical leadership. Formally, at least.
I was promoted to a software architect’s role to bring in that leadership. What I didn’t realize until later, was that I could’ve used a strategic directive from management right from the start.
I got nothing on that part. Operational goals from the business side, sure, but not strategic. Promotion, title and free reign. So I tried my best.
Off to work!
I formed a plan to organize the product’s internals to make it more clearly understandable while introducing small, but modern, improvements. Refactoring (I actually introduced this term to my colleagues), piece by piece.
I also developed a vision on where we should be headed and formed a team of senior developers so we could have open discussions about architectural matters once every two weeks, or once a month. Those meetings were held in the open for anyone to listen in, so that we could gain good point of views. No one objected to my vision.
These meetings eventually turned out quite unfruitful, as no one else even tried to bring ideas onto the table or said anything outside those meetings, for that matter. So I got no feedback. Unless it was to oppose something. All of this was not really helpful in regards to my job.
I also tried to get a better grasp of the bigger picture, but it didn’t take long until I was assigned to be a tech lead /developer on an internal project, and back as a regular developer I went. So as opposed to working even 50% of my time as an architect on one product, I barely made it to 10%. This percentage got even lower later on.
A year went by and I brought this issue up with management. I asked that I’d be granted the freedom to spend more time as an architect. They didn’t comply and instead came up with their own solution. Reorganize the team I was supposed to lead and give specific senior developers a promotion, so they could help me.
Unfortunately, this did not resolve the problem. It created a bigger one.
Two opposing fronts
The new team was formed, but I soon realized it was just as unfruitful as the last one.
I got no feedback. No one raised their hand about issues or even wanted to talk about them. No one presented any new ideas. Some were more than happy to oppose ideas, though. Very rarely someone brought up a topic we could discuss, related to some process that was slowing people down, but those were a rare occurrence.
It later became evident that there were two groups of people in this team.
On one side were a smaller number of people who actually educated themselves, explored new technologies and stayed up to date on the current landscape of the tech world. They saw that there were potential places where the product could be improved (on an architectural level) and brought those to everyone’s attention. They presented their ideas, or discussion points, and wanted to talk about them in a healthy way. This group also always went through the pros and cons of every idea, as there is no magic silver bullet in this industry.
In my honest opinion, these people deserve to be called architects. They actually saw the big picture and could think like an architect should when designing and developing solutions. They had also raised their hand and said to management:
“Hey! What about the architecture and design?”
And they fought for it. For years.
These people thought about modularity, flexibility, concurrency, resilience, cost (time and money, even on the long run) and all that good stuff.
Of course I’m very bias in this view as I count myself to be part of this group. But I also believe this should’ve been the level where every architect in the team should’ve been at so that healthy discussions could be held among peers, who hold similar senior positions. This way all options could be covered before making a decision everyone would be able to understand.
Some decisions were made over the course of time, of course, but often enough as more time passed some people tried to get the bigger decisions revoked as they either didn’t fully understand them, or just didn’t want change to happen. I tried my best to convince them, even demonstrating and explaining what the impact would be, but they were disinclined to even try to understand.
Other side of the table
Now, as I kind of already hinted, on the other side of the table were people who simply wanted for nothing to change. They pushed back on a lot of ideas, with no reasonable arguments to back them, and were unwilling to educate themselves on any topic, or develop their skills any further. Often enough they even persuaded management to their point of view behind the scenes, and when I heard about it, decisions were already made and the ball was rolling.
I eventually started to get frustrated.
I deeply respected the domain knowledge my peers had, but I felt as if I could not see eye to eye with them on a technological level. The difference in competence, skill, perspective on architectural matters and most importantly motivation to actually research important topics of discussion were simply too big to result in reasonable exchange of ideas. Smaller part of the team tried to think like an architect, while the other half only though as a developer would. And they were very vocal about their opinions.
This caused a toxic atmosphere to be born, where finding common ground was very hard. Meaningful discussions would easily turn into arguments and no decisions could be made. This killed any attempt at innovation.
So I had to leave when I saw a way out.
Why didn’t I continue the fight?
The reason for me quitting was purely selfish. I didn’t want to become stale. I need to be able to learn new things and be encouraged to do so. I want to be challenged in my way of thinking in a constructive and meaningful manner. Essentially I wanted to find a new level in software development!
I don’t want to spend my career disagreeing with people who are so keen on maintaining their current status, that they keep throwing wrenches in the gears to bring every attempt at a change to a halt. This was not the first time this had occurred. Even before I was assigned as an architect the same was happening with various other improvement efforts.
I got really lucky and came across a great job posting from a relatively big software company, and eventually received a good job offer from them. I’ve now taken my skills elsewhere, and I’m glad I did this.
If I hadn’t left, I would’ve most likely stepped down and asked to simply continue as a developer and not have the situation stressing me out any further.
Reflecting
During my time as a software architect I would’ve loved to gain actual feedback from developers, and try to work out any potential problems before they happened. I also would’ve liked to teach people more.
Unfortunately management treated me like any developer, so my time was consumed developing new features and fixing bugs. This limited my visibility quite a lot and I missed out on a lot of things.
I was bound to fail.
I did my share of mistakes. Not denying that. But I was open to improving myself, unlike others.
As a final side note, I recommend you to read “Turn the Ship Around! A True Story of Turning Followers Into Leaders”, a book written by David Marquet, a retired US navy captain. The title is quite catching, as “turning the ship around” was a phrase that was thrown around a lot at the company I worked for. My role did not encompass me turning people into leaders, as I was not actually their manager nor boss, but what I subconsciously tried to achieve was to embed the idea of operational excellence into people’s heads. This is also one of the pillars on AWS’s Well-Architected framework.
When people don’t strive for excellence, they tend to create big and slow process’ to avoid errors at all cost and simply settle for minimal passing performance.This kind of mentality easily leads to a lot of bottlenecks in the development process and to an organization that’s claiming it’s agile, while actually it’s quite rigid.
A week after my resignation a video was released in Youtube, where Robert “Uncle Bob” Martin & Allen Holub (both known tech authors, consultants and software developers) discuss how attempting to convince people of change can lead to a split in the developer ranks. This is exactly what happened to me, but unfortunately I was not an outside hire. You can watch them discuss this topic in the video below (one minute in length).
So don’t end up like me, but actually recognize these issues before it’s too late! And also, demand that management gives you a strategic directive as to what they want you to do in the next 2–4 years, so you don’t end up wasting time throwing attempts at a wall to see which of them stick. You are an expert in your field and most likely not even the CTO can tell you how to do your job. All management can do is give you a goal to aim for.
If you don’t have a goal, then what’s the point?
