Leadership In the Online Age: A Reflection On Team-Building
Join the DZone community and get the full member experience.Join For Free
|mr.switch? crs ferc|
for as many teams as i’ve had the privilege of leading, i’ve often been asked how i did it? how did i take six or seven individuals from different countries and turn them into a team? the question always catches me a bit off-guard because i don’t consciously do this – and i think that’s key. you can’t force anyone to work together as a real team and the harder you try the faster you’ll push them apart. plus, it’s currently a developers’ market. they can work wherever they want to and they know it ! how do you walk this tight-rope and successfully lead a team of rockstar developers?
clear and simplistic vision
here’s where agile excels as a process guide – don’t bog the team down in year long strategies! give them a compelling, short-term goal that’s achievable within a week or two:
- work with the business manager to get a simple, customer oriented backlog prioritized
- release latest at the end of every sprint
- rinse and repeat: your team will thank you for this predictable and stable environment
trust the team and delegate responsibilities
now that you’ve given your team the mission, stand back and get the hell out of their way. make sure they know they’re empowered to take every decision necessary as a team to achieve the goal you’ve set. as a scrum master, i took part in every daily standup, my mouth held firmly shut. i encouraged them to work directly together to solve their blockers, and, only when they couldn’t, did i step in to lend a hand.
never become a “rubber stamp” and get dragged in to approve every minor decision. if you’re ever asked something that you know another team member has better knowledge of, defer the question to them. “you should discuss that with mike and let me know if you can’t resolve it.”
ask for feedback and correct the course
sprint retrospectives are the most important scrum artifact you probably never use. after every release, circle the wagons and reflect on how things went, how they are going and how they should be . be honest and frank with your team about your impressions and ensure they are comfortable in giving a candid appraisal about their work and your role.
how you handle these feedback rounds will make or break you as a team lead. this is where you earn your teams’ trust . bend but don’t break (especially on strategic visions where you probably have a lot more insider knowledge). explain your reasoning openly and do your damnedest to improve their work environment.
i find that using the customers’ voice during these sessions helps the team understand difficult decisions. “yes, we all think it’s a cool idea but what value does it bring our users?”
technical integration platform for early development feedback
as a technical manager, the most powerful tool for teamwork is the responsibility for creating and maintaining the continuous integration system.
- instant build system for developers (each commit runs through all test cases)
- daily test system for qa and business (midnight update if build system is green)
- automated database imports for better testing (esp. performance)
- any build longer than 10 minutes is too long (add slaves, refactor, etc.)
keeping one eye on this system and constantly evolving it to match a rapidly progressing application environment is a tough job. your team may wonder at the effort you spend in running it, but, after a year, it will become the most critical system you have. “can we do a release? i don’t know – what does the build say?”
leading a modern development team is mainly about trust – your trust in the team and your team’s trust of you. to back up this “gut feeling”, get an automated ci system up and running as soon as possible. how do you instill trust in your team? share in the comments below or tweet @danackerson if you’d like more details!
Published at DZone with permission of Daniel Ackerson, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.