Adam Niedzielski

Happy teams create great products

Driving change - procedure and example

| Comments

One of my favourite topics during job interviews is driving change. “Do you remember a situation when you wanted to change some process in your team? How did you approach this situation? How did you convince your colleagues?”

Getting a buy-in from the rest of the team is, in my opinion, a very important skill for a senior developer. Just “knowing better” is not enough. You need to know how to explain the problem, present your solution, list the advantages, share the necessary context and knowledge, address concerns and divide the change into smaller steps.

In “The only constant is change – scaling our processes with weekly retrospectives” I’m showing how we’re using weekly retrospectives at Liefery as a starting point for driving change. If reflecting on the current team processes is an integral part of your culture then suggesting improvements is also much easier for your team members.

Another important thing about change is that it always takes time. In a mature team things won’t change just like that. Some changes have to be spread over a period of time. In “Our road from remote-friendly to remote-first” I’m describing one of the more interesting transformations that happened at Liefery and took over a year. It’s a good example of driving change and the blog post mentions a few different tools you can use to drive change.

Comments