#Tl;dr; Build relationships first, then build a reputation for your expertise, then implement changes.
Just for context, I’ve been working as a professional software developer for 22 years, but I let my career and knowledge stagnate until 2007 and became an “expert beginner” (https://daedtech.com/how-developers-stop-learning-rise-of-th...). I relaunched my career 11 years ago this month. So, how I’ve approached “what to change”, changed over the years...
2007 - started working at a small company. I took the job because they were looking for high level junior developers and were transistioning from VB6 to C# and they had a C++/MFC framework. It was the perfect position for me. I was really good at both their old technology and I was just getting into C#.
I didn’t try to change anything. I took the job to get some real world modern development experience and soaked everything in.
2011 - that company went out of business but by then, I knew C#, I could talk the talk about modern software engineering practices but I still needed more experience. I got a job at a Fortune 10 (at the time) company and learned how modern large software teams and organizations worked and was there to learn, not to change things. I took what I learned and leveraged it and my by then 20 years of on paper experience to get a job where they wanted someone to make significant changes to a slow moving dysfunctional software development department....
Again: My goal wasn’t to make changes, it was to keep my head down, not ruffle feathers and learn.
2014 - With both my manager’s and his manager’s blessing, I along with the other developers they hired, went in and started trying to make changes in the CI/CD process, getting rid of some bespoke custom libraries that could be implemented better using popular Nuget packages, and changing the testing process like bulls in china shop completely disregarding the feelings of the old guard. Eventually the old guard won, pushing both managers out and leaving the new hires without any cover.
Lessons learned: Build relationships first, respect the past decisions that got the company to where it is, and remember one of the “Laws of Power”, “Law 45: Preach the Need for Change But Never Reform Too Much at Once”. Try to win people over based on building relationships.
2016 - I started working at a new company with the official title of “Team Lead” where I was brought in to modernize the development department. I learned my lesson, first I built relationships, I respected the work the team did, engendered respect, and earned the loyalty of the team. Even though I had role power, I realized that wasn’t going to be effective without the relationship power.
I implemented version control, a real CI/CD process, automated testing, documentation standards, fought to reduce needless meetings and fought for the “40 hour work week”.
2017: I got another job at a small company as “just” a senior developer and an equal on paper. I quickly started building relationships and proving my expertise. I have far more influence to make changes based solely on doing that than I have ever had before.
Automation is always my hobby horse. First I implemented a sane CI/CD process and configuration management.
The next thing I’ve worked on is getting rid of single points of failure in both systems and people - I’m encouraging cross trainings.
Just for context, I’ve been working as a professional software developer for 22 years, but I let my career and knowledge stagnate until 2007 and became an “expert beginner” (https://daedtech.com/how-developers-stop-learning-rise-of-th...). I relaunched my career 11 years ago this month. So, how I’ve approached “what to change”, changed over the years...
2007 - started working at a small company. I took the job because they were looking for high level junior developers and were transistioning from VB6 to C# and they had a C++/MFC framework. It was the perfect position for me. I was really good at both their old technology and I was just getting into C#.
I didn’t try to change anything. I took the job to get some real world modern development experience and soaked everything in.
2011 - that company went out of business but by then, I knew C#, I could talk the talk about modern software engineering practices but I still needed more experience. I got a job at a Fortune 10 (at the time) company and learned how modern large software teams and organizations worked and was there to learn, not to change things. I took what I learned and leveraged it and my by then 20 years of on paper experience to get a job where they wanted someone to make significant changes to a slow moving dysfunctional software development department....
Again: My goal wasn’t to make changes, it was to keep my head down, not ruffle feathers and learn.
2014 - With both my manager’s and his manager’s blessing, I along with the other developers they hired, went in and started trying to make changes in the CI/CD process, getting rid of some bespoke custom libraries that could be implemented better using popular Nuget packages, and changing the testing process like bulls in china shop completely disregarding the feelings of the old guard. Eventually the old guard won, pushing both managers out and leaving the new hires without any cover.
Lessons learned: Build relationships first, respect the past decisions that got the company to where it is, and remember one of the “Laws of Power”, “Law 45: Preach the Need for Change But Never Reform Too Much at Once”. Try to win people over based on building relationships.
2016 - I started working at a new company with the official title of “Team Lead” where I was brought in to modernize the development department. I learned my lesson, first I built relationships, I respected the work the team did, engendered respect, and earned the loyalty of the team. Even though I had role power, I realized that wasn’t going to be effective without the relationship power.
I implemented version control, a real CI/CD process, automated testing, documentation standards, fought to reduce needless meetings and fought for the “40 hour work week”.
2017: I got another job at a small company as “just” a senior developer and an equal on paper. I quickly started building relationships and proving my expertise. I have far more influence to make changes based solely on doing that than I have ever had before.
Automation is always my hobby horse. First I implemented a sane CI/CD process and configuration management.
The next thing I’ve worked on is getting rid of single points of failure in both systems and people - I’m encouraging cross trainings.