What I value most about working at Devbridge is the way we differentiate ourselves when it comes to team dynamic, efficiency, and collaboration. I’ve worked at a variety of consulting firms and had the misfortune of observing some pretty dysfunctional situations. I think it’s important to highlight what Devbridge gets right and why it provides superior products and experiences for clients—as well as a great working environment for our own teams.
When I first started at Devbridge, I was beyond skeptical. I had been jaded by some pretty oppressive conditions in prior roles. Honestly, I was kind of annoyed at how everyone at the office kept touting the speed and quality of Devbridge’s teams. Yah, yah, whatever guys. I know we need to pitch clients and all, but why are you selling me? I work here. But guess who became one of those annoying sops in just under two months?!
My first project with the company really showed me what we were made of. I was handed a three-slide presentation outlining some ideas from the primary client stakeholder, a team (most of which was based in Lithuania), and a time-box of two months to ship the first version of a product. Confession: I laughed out loud. To my astonishment, we had a functional application in production in nine weeks. It was the fastest bespoke new product release I had ever experienced. How did we achieve such an accomplishment?
The answer: It was the team. The way they worked (and taught me to work) was truly an art. Below is a list of what I learned then and continue to practice today.
The listicle! Top 10 tips for successful teams
1. Work as a team.
As trite as it sounds, true collaboration is absolutely key. So many product teams are made up of a set of individuals who function independently and are working together for the first time. I was admittedly a bit of a wild card on my first endeavor at Devbridge. The majority of the team knew one another and had already developed a working cadence. This not only contributed to economy of communications, but also provided a comfort level with task execution. No one person was an island. Everything we did was a team effort with individuals contributing as necessary.
2. Foster personal connections—even remotely.
Another confession: I loathe being on camera. I had to get over myself and learn to embrace the camera to be effective at Devbridge. Working with geographically dispersed teams is quite normal these days. The communication loss from not being able to see others can be costly. By leveraging teleconferencing and instant-messaging tools, as well as injecting a bit of our personalities into our professional communications via email, we were able to bond as a team despite being on different continents. Now, as a more seasoned Devbridger, I can still say that I am confident every member of each team I have worked with has always had my back. Part of that assurance is the human connection —seeing one another live or in person and getting to know everyone.
3. Be accountable, really.
There is a lot of rubbish out there about “holding people accountable.” That is not what I am talking about here. I am talking about each and every member living accountability—not because someone in a perceived authority role said so—but out of an internal desire to excel at what we do and elevate the entire team. We hire for this quality and foster it ferociously. Part of our success is that we live our company values of “Take Ownership” and “Seek Mastery”—equal in importance is “Have Fun.”
4. Hold efficient meetings.
I was amazed at how effective our sprint ceremonies were on that first project—even from day one. The reality of working an eight-hour time difference away from a good portion of my team was that we just couldn’t afford to waste any time. We made a concerted effort to schedule meetings in the small window of overlapping working hours across time zones and defined a working process in advance to maximize outcomes. As a result, that necessity led to clear, concise communications and quick escalation of anything that truly required attention. As someone who has often received feedback that I am a bit too abrupt, I found this quite refreshing. Although I still spent the requisite amount of time in client-facing meetings discussing the weather and dodging political topics, our internal meetings were direct and highly effective, and there was even time to joke around a bit in the last few minutes.
The biggest differentiators for effective meetings are:
Establishing a team culture of directness (it’s OK to get right to the point).
Making sure everyone understands the meeting purpose in advance.
Ensuring everyone comes prepared. Sometimes, this could mean self-study and sometimes even (oh, dread!) a pre-meeting to align on precise agenda.
Not being afraid to call out agenda diversions. Be comfortable saying, “Let’s take that offline,” and actually enforcing it is paramount.
5. Be transparent, really.
Going back to that first project, everyone always knew who was working on what (and why). We had a tightly managed, centralized sprint board. We talked daily and spoke up immediately when something was needed. We embodied transparency.
Two transparent examples:
When I met with the client and found out that we were out of alignment on a feature set, I informed the team immediately, and we were able to adjust within our time-box to deliver on the amended vision.
When I wasn’t providing enough detail in the user stories for the team to start development, we discussed it right away, and I added the needed information. The team didn’t hold back correcting me just because I was in what is traditionally seen as a leadership role.
Part and parcel of efficiency is transparency. Whether in a team setting or individually, transparency coupled with feedback fosters growth. According to one of the engineering team leads I’ve worked with, the most effective feedback is constructive, provides exact timing, says what was good or bad, informs how it affected the team, and offers actionable items.
6. Be humble.
Extrapolating Alexander Pope a bit…if to err is human and to forgive divine, then to just get over yourself and fix it as quickly as possible must be other-worldly. One of the huge inhibitors to project success in my previous work-life was an unwillingness to admit fault or truly own a mistake. Hiding errors or not adjusting due to pride can have irreparable, negative impacts on timeline, trust, and quality of work. At Devbridge, the team demonstrates humility in their complete acceptance of correction from one another and immediate adjustment to create a better product and team dynamic.
7. Play the strengths.
Another toxic habit is getting too fixated on project roles or job descriptions. I have been shut down numerous times in my career for offering an opinion or asking a question about something that was “not my job.” This kind of territorial attitude inhibits collaboration, destroys morale, and leads to inferior output.
Some examples of role-bending contributions to drive success:
QA recommending feature enhancements for business value.
Engineers challenging UX patterns.
Every team member contributing to acceptance criteria.
PM voicing a technical concern
8. Encourage comfort with ambiguity.
Seasoned software project professionals will often say that comfort with the unknown comes with years of experience. I disagree. Even the greenest team members at Devbridge are encouraged to embrace ambiguity and either fill the gaps with assumptions to prove out or clarify until they can proceed. This is truly an agile team at its best.
On a recent project, our first couple of sprints very quickly showed that the client stakeholders had some assumptions that were not articulated in the requirements. By our third demo, we were back on track for alignment, which would never have been possible if the team had stopped work in Sprint 1 due to ambiguous criteria. Although it seems counterintuitive, commitment to a potential micro-failure is one of the fastest ways to success.
9. Retro right. Retro everything. Retro often.
Yet another confession (surely, I’ll sleep well tonight!): I used to hate retrospectives. I disliked them so much that I am guilty of scheduling days off just to avoid them. Why? We were doing them all wrong. Retros used to be a time for our project manager to tell us that we had failed, that we had to get better, and by what percentage we needed to improve. They devolved into sessions of passing blame around without any proposed solutions or actions for improvement. I recall a particularly awful meeting in which someone in a position of authority used a tone not unlike what you might hear used for schoolchildren, “Now, what did we all agree we were going to do before moving things to the Done column?” Fail.
Now that I understand the value of real, open feedback retros, I love them. I even retro parts of my personal life. (Next time we do a group train journey, we’ll pack more snacks and make sure we have more time for connections!)
How to retro:
Create a safe, judgement-free environment for sharing.
Allow everyone (really, everyone) an opportunity to speak freely.
Listen and reframe if needed for clarity.
Reserve time to talk about what went well—always.
Listen.
Focus on improving things your team has the power to change.
Listen.
Collaborate on action items for improvement.
Keep listening. Some team members might want to discuss things one-on-one afterward.
Once you’ve got the basics down, it’s a good idea to vary the facilitation. Some team members are more vocal than others, which can skew the feedback a bit. By changing up the style, the team has different types of opportunities to contribute in ways that might feel more comfortable.
One of my recent favorite retros was when an engineering team lead used image cards from the table game Dixit. Each team member selected a card to represent how he or she felt about the sprint, and the rest of the team tried to guess what the person who chose the card meant. It was not only great insight into how the team had worked together over the last two weeks, but it also gave a glimpse into how each team member thought and viewed others.
10. Actually evolve.
Once you identify how to improve as a team, do it! Assign actions and follow up on them. Communicate with the team about progress, any shifts, and what is different (better or worse) as a result.
A great example.
One of my teams used continuous improvement to address code reviews.
I was working with a team that was really focused on their individual tasks one sprint and ignored the items ready for peer review. The result was that only about half of the target scope for the sprint was completed within the two-week window. Not good.
Had the team underperformed? Were they suddenly working more slowly?
Nope. We didn’t prioritize reviewing one another’s work, so items got stuck in review status. We discussed in retro, took action to reprioritize, and continued to emphasize the importance of this shift in our standups. Result: We didn’t just meet the goals for the next sprint; we exceeded them.
The willingness to adjust for the larger goals of the team is one of the most valuable attributes any product team member can have. Ultimately, a well-run team can do far more than any individual. Realizing how to be part of a team dynamic is crucial. Each team—and each project or release—is a bit different, so the need for evolution is constant.
The secret to (our) team success
Regardless of the external challenges with product delivery, the most important success factor is the way the team interacts and executes. A high-functioning team built on trust can overcome the typical software project blockers far more efficiently and even become stronger as a result. How can you promote this change in your organization? Get to know your colleagues. Challenge current culture constraints. Lead by example. Devbridge is an organization that lives by these concepts, which results in both a successful company and a rewarding work environment.
