I know you may think this topic is familiar. I mean, I did talk about it in my previous post about how you decide which package to take. But in this post, I’m going to be discussing this in broader terms. Think in terms of, frameworks, languages, tools, or debates in the company, or experimentation. How do you decide which direction you want to take in terms of technology? That’s what this post is about. Being a leader and promoting healthy dialogue.
You shouldn’t be a technology dictator. Nor should your company be a complete democracy because you’ll never please anyone. But you do need to be open to discussions around which technologies you want to adopt and how to have a healthy debate about them. I’ve found that sometimes in your team, you’ll have one (or two) really passionate people. They want to push this new technology that they’ve read about. It has an awesome community and it is growing fast. But hold on. Before you encourage them to go ahead and push that through your system, you should do some research yourself. Now, that you’ve researched it, you think it’s not a great solution after all. How do you have a healthy debate with your colleague?
Firstly, you shouldn’t just say no. You’ll disenfranchise your colleague. She’ll no longer want to bring ideas to you if you just say no without a reason. Even if you give a reason and there’s no room for debate, she’s likely to not speak up again. In my opinion, you need to foster a debate. You need to sit down with the entire team and have your colleague present the new technology and the reasons why. You can help the debate by bringing in what you think the cons are. You’ll then have your colleague thinking about costs that maybe she didn’t think of. If she has an answer for your concerns that’s satisfactory, maybe you try the new tech. Or maybe not. Maybe you still decide the cons outweigh the pros and you tell your team and colleagues why. If they’re valid, you may still have disagreements, but at least they’ll know why.
One thing you can do is experiment with new technologies or new processes. Why don’t you create that POC (Proof of Concept)? Try it out. Let your colleagues know what you think of it. Let them test it out too. Show them the code. Currently, we like to experiment with our process every sprint. How is that time tracking going? Don’t like it? Talk about it at the retrospective and change it for the next sprint. What worked? What didn’t? Are you just going around in circles? How can you get out of this rut?
Here’s an example from my team on experimentation on sprints. When we first started, we started out with a manual burndown chart. One of those that you can print off from the internet and create a line graph tracking your progress over the sprint. However, what we found is that no one took ownership over the chart and it ended up that the chart would be completed the day before sprint review with estimations of what we did each day. What we decided to experiment with, was everyone tracking their time in JIRA. JIRA has an automatic burndown creation. This ended up being our new way to record hours done and track our progress. It’s more work for everyone, sure, but everyone takes ownership of the data. Not just one person.
You should definitely foster healthy debate within your team. It’ll help in the long run and everyone will trust you as a leader, even if they think you’re making the wrong decision. And if it is the wrong decision, you can always change it later. Experiment with new technologies and processes. Don’t be afraid of change. But also don’t dive headfirst into the pool. You never know what creatures might be lurking under the water.