Changing the status quo and adopting new technologies is never easy. Whether we are talking about a new database, library or even way of approaching your problems, you should know what your are in for.
Of course, your difficulties will be very different depending on the size and culture of your team!
Do you even want to get started ?
-
What are the Benefits ? Whether it is ease of development, transparency, adaptability, performance... A case has to be made.
- Knowledge : you should know the manual/tutorials inside and out. For bleeding edge projects, you should have read some of the source.
- Experience: before you make everyone adopt something, you really should have toyed with it and it should have proved itself in a non-critical project. Ask around what people think.
- Trust/Authority and commitment: can you push this through?
What will make the project successful?
- Running code and rough consensus: do things, write code, take responsibility, and steer discussions away from uninformed opinions and towards what brings the most value.
- Don't break things without reason. Provide guidance and automation to update/migrate downstream clients/users. Backward compatibility is boring but everybody will thank you for it.
- Onboarding: give assistance setting things up. Give advice about best practices. Offer solutions, do the work.
- Support: if you've built a consensus and brought people on board, don't waste everything. Proactively check-in with your colleagues, ask how things are going. Treat your your coworkers as clients.
At some point you will need to evaluate your project:
- Be unbiased: consider all options, give fair assessments, be transparent, and always keep in mind what is most important to your team or users.
- Feedback: is huge. Only if you listen can you improve your work, or cut your losses early.
Personally, in every new project I try to do two things like I've never done before. Never more, rarely less than two. It's great for learning, and soon you learn to judge things better. Changing existing projects and workflows is much more challenging: be gentle 😌.
Did you like this post? Read more at https://talk.shapescience.xyz :)
Top comments (1)
I have learned you need to make a business case. "This is the future of the industry!" or "all the best practices recommend this" have never been convincing arguments that worked for me. I had to prove that a technology would cut development time, reduce errors, save money, and so forth. There were plenty of times where I could have said "I told you so!" with a smartass grin months down the line, but it wasn't their fault; it was mine for communicating poorly and reasoning on a level which makes sense to the company and not just my strong opinions on tooling and languages.
Different people look for different things. I have known managers who were afraid of any new technology and preferred to rely on older, enterprise solutions. I can't tell if it was because new tech made them feel insecure, they have been burnt plenty of times by promising new technologies, or that they know far more about their approach than I am aware of, leading me to pitch the wrong things.
Unfortunately, you will often have to come up with a proof of concept to convince others ultimately. Sometimes that means writing a pet project on the weekend to demo if yo don't have sme bench time at work.