Description by @torok_tomi
In software development it's more likely now than ever, that as a manager, you'll face the challenge of leading a fully or at least partially distributed developer team. It's a brand new thing for everyone, but Tim Olshansky, current VP of Engineering at Zenput has faced this already. In this interview he shares what he learned on managing distributed developer teams over the years, and gives you actionable tips on making it work as well as possible.
Episode details
In software development it's more likely now than ever, that as a manager, you'll face the challenge of leading a fully or at least partially distributed developer team. It's a brand new thing for everyone, but Tim Olshansky, current VP of Engineering at Zenput has faced this already. In this interview he shares what he learned on managing distributed developer teams over the years, and gives you actionable tips on making it work as well as possible. In this episode, we're covering: -Challenges of managing a distributed developer team -On-boarding remote engineers -Balancing synchronous and asynchronous work -Managing distributed developer teams -Measuring productivity at distributed developer teams -Giving feedback in distributed developer teams -Running meetings in distributed developer teams -Management tools at distributed developer teams Excerpt from the interview: "I don't measure productivity specifically. It’s been a struggle, because the definition of productivity is a difficult one, particularly in the software engineering world. Is fixing a hundred bugs or implementing ten features better? What if none of those features affect the company positively? Firstly, I start by making sure we're working on the right things. If not, I try to fix that, because all the productivity in the world working on the wrong things is not going to get us where we need to be. The next question: are we working the right way? Are we doing things that are going to cost us in the long run? This is a classic technical debt conversation. Do we have the infrastructure to support the team to be productive? Does the team have to overcome difficulties to demonstrate what they've done? I try to assess those things and remove the impediments. Then the team can focus on doing what they like, which is problem-solving, and building new things. When all this is sorted, I look at the individual level. There, I see that if they say they're going to do something , do they get it done? If not, why not? Sometimes, folks need to be held accountable for what they commit to..."
Comments
Add new comment
Login to comment