Is the latest technology the key to your team’s success, or is there something else?

Developer Support

App Dev Manager Yulia Willmore explores what makes a project more successful – is it really the latest and greatest technology, or a simple team dynamic?

About a year ago, I joined Microsoft. For the first several months, it was a whirlwind of trainings, traveling to trainings, meeting many amazing people, and learning a million tools and processes. One of many required trainings I went to was called “Developing Applications the Microsoft Way”. Our group was about 50 or so people of new hires from all sorts of backgrounds and experiences – including fresh-out-of-college graduates, seasoned professionals, and everything in between from different parts of U.S. and other countries. The preliminary details of this training weren’t all that detailed, with just a couple of pre-requisites around scrum/agile processes. From the title of that training, some of us assumed (me included), that we were going to be taught the tools, software, and processes to develop modern, innovative, and cutting edge applications – after all the title included “the Microsoft Way”, right? How it unfolded was actually much more impactful for my career and myself as an individual and a team player beyond any specific tools.

Right away, we learned, the training was going to be a week-long project in a form of a group’s competition, and the set up was straight-forward. The facilitators role-played a scenario of a made-up organization, “the client”, that had various needs, goals, challenges, blockers – essentially the requirements of a “pie in the sky.” This was not much different from the real world projects we support as dev teams. Then we were broken up into smaller groups of about 6-7 semi-random people (loosely based on our career backgrounds so as to have a good mix of experiences on each team). We were in individual teams who got the same client requirements and the ONLY requirement from the Microsoft facilitators was to organize our user stories, build a working solution using agile methodology with Azure DevOps as our project tool, and present it at the end. That’s it. They didn’t say we must make a website, some system, or some application. We were asked to solve the client’s pain points– period. As individual teams now, we were given one other chance to probe the “client” with any additional questions. Then, we had four days to come up with the plan, build a functioning solution – feasible to be done in that time frame, and present it to the “client” and the entire group.

As one can imagine, in that moment, we experienced many different emotions with what seemed like a daunting task. What made it less daunting, the facilitators reminded us, was that we are not alone – we are team – so, leverage each other. Over those few days, I’ve observed and experienced interesting things. Just like in a Petri dish it was very revealing to see how certain variances produced different end results. In our case, we had no control over who is on our team (much like in real world when we join new teams). We naturally went through what is commonly known as the Tuckman’s Team & Group Development model – each of our groups experienced all stages – forming, storming, norming, performing, and adjourning. Every group had variances like having colorful characters, quiet powerhouses, highly skilled but humble engineers, never-stopping-talkers, sprinkled with a know-it-all here and there (what would the world be like without them, right?), but mostly down-right smart and exceptional humans with vast backgrounds and amazing life stories.

Machine generated alternative text: •tittle•ement •Undearpurpcm •Guidance and Forming Storming •Increased clarity •Power Str.ks and •CJear Wes and •Facilitatkn Norming Performing •Clear Viém and •Ftxuson goal •la* completion •Good f«fling abwt •Jknnitim Adjourning

It wouldn’t be surprising to say that the makeup of each team’s skills directly impacted the technology that team chose to build the solution. Each team, of course, gravitated to using the technology they knew best. But what ultimately became a differentiator in the final result was not the crazy, awesome technical talent and tools they were using, but rather how well the team jelled together. The team dynamic was the differentiator in how innovative, creative, and ultimately most appealing to the customer the product was.

To demonstrate – we had six teams that each came up with very different solutions. Some of them where apps with brilliant ideas, some quite functional websites with integrations, some were a bit more “fluffy” with visuals, and some were just pure, gorgeous and no-frill function. All were very close, but the one that stood out didn’t have the most functional and complete product with exact specs. In fact, it didn’t have many of the requirements complete at all. But what they did have was not what that customer wanted all at once (that pie in the sky), but what the customer needed right now to function, and then a clear roadmap of what will be in place in the coming sprints. The real “bow on the box” was the team’s extreme ownership and care, as well as delivery of their presentation and their dynamic. The whole team came to the front of the room (not just one or two designated or self-appointed speakers). They had a polished presentation – clean and logical – with some demonstration of the functionality. All took turns to speak and used humor where things weren’t quite functioning as they were expecting. They were articulate, yet not rigid, with eye contact and acknowledgement of the customer’s pain points. Their dynamic was warm and customer-centric. They owned the imperfections too. They all had varying skill sets, but they leveraged each other’s strengths so well, it was beautiful!

In contrast, even though several teams’ solutions were in some ways more superior in functionality and looks, some of the teams’ dysfunction which they weren’t able to get over during the storming stages seeped through in their delivery. The egos and frustrations showed, and the energy was very different.

In the end, there were as many solutions as there were developers/teams – the same problem was solved different ways. But the winner came through based in large part on the culture they created within. Because of that, they were the most effective and appealing to the client. Pure and simple. It’s ok the product wasn’t perfect. Perfection will come in future iterations. The customer got to experience what the product will be and what team will be building it.

The takeaway is – don’t underestimate the power of a team dynamic your product becomes the result of it. The established and protected culture of acceptance, the embracing of diversity, the maximizing of the strengths of your team – all this beats any latest and greatest technology. The tools are just that – they are tools. And what at the core of “Developing the Microsoft Way” is simply people and their capabilities to create a wonderful client experience however imperfect it is at the moment. Focus on building your team’s culture, then model it, infuse it with positivity and empowerment, care what goes on within the team, show extreme ownership, go the extra mile (or an inch – whatever it takes), the team as a whole will absorb it, then will perform, deliver, and win over the customer.



Discussion is closed.

Feedback usabilla icon