Architecting a Developer Team Turnaround

A couple years ago, I accepted a position as the “director of digital” at a small marketing firm. And yes, there was still a divide between digital and traditional work there. I was mostly hired for my strategy capabilities and my successes with analyzing digital web properties and finding areas for growth. The title was just that, a title, as I had no direct reports and was only responsible for my own work.

Like many people in leadership positions, I found myself there accidentally. After several months as the resident strategist, I was appointed the leader over the tech team, which consisted of a few developers, a BA, a handful of digital technologists, and the interns.

At the time, the agency was going through a rough patch. In general, the culture was quite toxic. The company’s leaders were at odds with each other, and this created what I can only describe as “camps” of employees who positioned themselves with one of the three founders. As you can imagine, this put most of the employees at odds and created a lot of distrust. The only thing that was consistently working across the company was the gossip machine. Things weren’t much better with the tech group. My team had an “us versus them” mentality because “they don’t get us.”

This was a tricky situation for a newly appointed leader to walk into. I identified a company that had lost its purpose and direction, and a culture that had gone sour from constant frustration and disappointment. I was all the more intimidated after I went to a good friend and colleague for advice about the situation and she said, “You should probably look for something else and jump out of that crazy salad.” No help there.

Someone once told me that if you see it, it’s your job. And I could see all the problems. I knew that while I couldn’t solve them all, I could at least make changes within my team and hope that our changes would create a positive effect on the rest of the negative culture.

Faced with a difficult turnaround situation, I leaned into my strategic planning skills and did what any strategist would do first: analysis.

Current state analysis

You can’t plan your way forward until you know where you’re at. While I was clear on the general problems the team had (they were certainly eager to vent about them), I wasn’t clear about why these things were happening and who owned the problems. I started my analysis by asking each person on my team questions, like:

• What are the current challenges to producing your best work?
• How do our processes and policies either help or hinder your work?
• Are you doing the work you love to do?
• Do you have all the tools you need to do your best work?
• How can I help you do your best work?

I documented the answers and highlighted common themes, and through that I was able to find some key insights behind most of our difficulties.

Future state and gap planning

The next step in my strategic turnaround process was to let the team dream a little. This was the fun part. I got my team together and led them in a visioning exercise where we got to think about our ideal team state. I asked questions like:

• What tools, technologies, and sites would you build if you had the freedom to do so?
• If you ran the place, what would you change first?
• What does the perfect work day look like to you?
• Talk about when you were the most productive you’ve ever been.
• What are your strengths and what are the strengths of your team members?

Armed with the current state and the team’s ideas about their ideal future state, I could then identify the gap. Ours was a wide one, but I was able to weigh and prioritize those initiatives that I felt we could feasibly change, that we would be willing to commit to, and that would have a positive impact on the rest of the organization. We identified three key areas where we could control and implement improvements.

1. Team process improvements: We focused on meaningful changes that would help us optimize our project process and cadence. For example, instead of a big, one-hour long Monday morning meeting, we instituted quick 15-minute stand-ups at the start of each day to align tasks with our strategic goals. We also got rid of the technologies we all hated and streamlined down to Slack and one other tool.
2. Tech team camaraderie: This consisted of simple, consistent things we could do to deepen relationships and build positive feelings about work, such as Friday afternoon celebrations at the bar down the street and  daily 20-minute team walking meetings around the neighborhood.
3. Inclusion of other teams into our work: In order to break down the “us versus them” barrier, we needed to formalize engagement across team structures. I challenged my team to respond to “they don’t get us” with ideas for how to help them. Each of my team members took a topic and created a slide deck and we hosted “lunch and learns” for the entire agency to teach them different topics we were interested in. This was a successful effort. After one session we got most of the account team to use Markdown, for example.

Turnaround like a software sprint

We treated each of these areas like software development epics on a sprint board. Each key area had individual tactics, deliverables, owners, and success criteria. I appointed a scrum master, and each person had work projects they were responsible for completing. Then, as we executed, we kept track of our progress. We held regular meetings to review our individual projects and discuss blockers.

So what were the results? Running our “culture betterment” initiative in this manner did a few things that I could not have planned for:

1. It aligned my team behind a clearly defined, clearly communicated, and well-structured purpose; which led to….
2. A team that became advocates for making positive changes in the organization and evangelists for our cause; which resulted in….
3. The rest of the company beginning to appreciate and adopt our positivity. The momentum we created with our sprinting led to changes across other teams as well.

I’m sympathetic to developers-turned-leaders who find themselves in the midst of challenging team culture situations. It can feel overwhelming, and the mountain can seem unscalable. But just like I leaned into my strategy background for the solution, dev leaders can leverage what they do best: problem solving. You probably already have systematic ways you troubleshoot a particular problem in code. See if the same framework could apply to your team. Do you assess, sketch, reverse engineer, test, or ideate? These same processes can apply to challenges within your team. I encourage any leader in a turnaround situation to leverage their experience, use it to reframe the situation, and empower their team to take ownership. The results can be deep and lasting, not to mention highly satisfying.

Jayme Thomason is not only an editor for BuildBetter magazine, she has spent her 12-year career solving the most complex digital challenges for companies of all sizes. She has built several successful businesses, including software company, DivvyHQ and her latest venture, Brink Insights, where her team of technical experts helps software companies analyze their digital systems, uncover opportunities for growth and implement experiments to find core drivers of business.

Connect with Jayme on:  Twitter

Also Read-https://stackify.com/build-success-using-mvps-in-software-development/

Author

Alexandra

More articles by Alexandra