Embrace the changes, and love the problems
“Still don’t know what I was waitin’ for
And my time was runnin’ wild
A million dead end streets and
Every time I thought I’d got it made
It seemed the taste was not so sweet
So I turned myself to face me
But I’ve never caught a glimpse
How the others must see the faker
I’m much too fast to take that test”
–David Bowie, Changes
You’ve just joined a new team, but the technology being used isn’t implemented quite as you’d expect. What should (or shouldn’t) you do?
I’d like to share some thoughts on moving between teams or finding new ways to adapt new technologies so that others might learn from my experience. There are certain things I’d advise you to do, and others that I’d advise against. In this article, I’ll address the technical aspects of changing teams
Learn the problems, and fall in love with them
Falling in love with the problems your team encounters is critical. Wait, what?!
There is a role called Innovation Catalyst (IC), and as part of that role, the IC identifies problems in order to find a solution. This approach can lead to finding more than one solution and opening up new paths and ways of thinking.
Here is an example I encountered some time ago: I joined a team where one of their tools was based on a testing tool. I never encountered such a scenario before. They needed to use this tool due to organization-wide constraints. Before adding any new technology, they needed to perform penetration tests and additional adaptation.
But the team had a problem: They needed to perform authentication in the way a normal user would and not programmatically. Once I understood the problem, we were able to work together to find a solution.
On testing and maturity level
Let’s face it: Tests are not sexy, but they are critical for understanding what the maturity level of a product is.
We as developers should try to cover as many scenarios as we can. We might intend a program to run along a happy path, but the end user might encounter a critical path or errors. Therefore, we need to cover as many scenarios as possible when testing.
A while ago, I was a part of a team that ran all tests manually. We ended up doing regression testing for the entire product manually before each deployment. In the end, we deployed a faulty product to production — and we just so happened to have a demo scheduled for the same day.
Clearly, we learned from this experience. By gradually sharing new methods to write deeper tests, we could cover not just the happy paths but also the places where the code might break. As a side effect, we also reduced deployment time and improved testing efficacy.
Monitoring, dashboards, runbooks, and onboarding
I can hear you all yawn. These topics are nothing new, and they’re not terribly exciting, but they can teach us a lot about how a project is being addressed.
From dashboards, we can see what is being monitored and compare it to the problems that were introduced. Now the question is, are all the problems being tracked? Can we pinpoint the root cause easily and quickly? Do we mark these problems in the runbooks, and are they reflected on our dashboards?
And what about onboarding processes and documentation? Do we have all manuals and resources in one place? Do we need to have someone point us to resources like databases due to lack of access? Is there a detailed, up-to-date installation manual?
All of these topics are related. They indicate the ability to address problems that we as a team might encounter.
If you think you’ve found some gaps, you can always try adding some monitoring and dashboards, which is a win-win situation for everyone. Your team will gain some new monitoring, and you will gain a deeper knowledge of workflows.
The same goes for updating the runbooks and onboarding manuals. Doing so will increase your understanding of how the services and applications work. This can reveal dependencies and possibly lead to the removal of some unneeded parts.
Technology gaps
Here comes the hardest part for me. I love new technology, and I love AWS’ well-architected solutions approach. I know it impacted Google and Azure, but it’s not that straightforward. Some teams have technology gaps, and some teams have limitations due to company constraints or other issues.
That being said, it takes time to understand why a team uses a particular tech stack. Once it’s clear, though, you can offer alternatives.
For example, there is a need for a new API that will be called repeatedly many times, and local cache is currently being used. Offering alternatives is tricky, but it’s a critical challenge.
When I have faced this challenge in the past, I created more than one alternative and added a pros and cons document for each solution to compare to the current solution. The most important part is that I did this without saying anything negative about the current solution! Then I shared the pros and cons documents with the team so that we could decide on the right solution. The main point here is to share new ideas, to gather honest feedback from everyone, and to adjust the proposed alternative accordingly.
What not to do
Here’s what you should avoid when you offer alternatives:
- Don’t blame
- Don’t be arrogant
- Don’t share destructive criticism
You don’t know the road your new team traveled to get where they are. They may have lacked knowledge or a solid roadmap, not to mention numerous other challenges.
Also be sure to avoid exaggeration. A process may or may not be working, but exaggerating the downsides will only cause tension. And don’t forget that perfection does not exist. So, to say you have found the perfect solution is not only dishonest; it is sure to cause antagonism.
I will summarize with a quote from Confucius:
“Don’t do unto others what you don’t want done unto you.”
Some final words
“A river cuts through a rock not because of its power but because of its persistence.”
–James N Watkins
Every product, system, and team I’ve worked with has had gaps. But we as a team (not as individuals) need to discover the root causes of these gaps. The best way to share new ideas is to do so gradually, after learning the processes and the product, the team’s history and their pain points.
As I see it, if you force someone to do something, they will never truly see the benefits. Instead, the change needs to happen with the buy-in of the entire team, with ideas introduced gradually to limit tension and garner support.
Happy coding, and enjoy the ride!