Return to site

Deliver on the promise of self-directed teams

A "how to" guide for building & leading the team(s) of your dreams...

· leadership,team building

You read dozens of books on agile and hundreds of articles, but no one actually told you how to build the team(s) of your dreams. This article changes that.

Understand your audience

Many leaders thinks software professionals are a tricky bunch. This stems from not understanding who they really are and what drives them.

Bringing order to chaos is the job description for a software professional. Engineers connect thousands to millions of logical statements together to solve complex business problems. That's a huge task, and because order brings simplicity, many teams rely on frameworks to help achieve that goal.

With a framework in place, an engineer stops worrying about everything that framework does for them. Your team can focus on solving your unique business problem instead of building yet another solution to an old problem that's been solved hundreds to thousands of times. Data storage, responsive web interfaces, and security are pieces of code teams almost never write from scratch. They rely on frameworks to do it for them.

Look around and identify the mistakes that are being made over and over by your team(s). Do a little research, and you'll find that many other folks struggle with those same issues. Dig a little deeper and you'll see that someone published a "framework" to help other solve that same problem. It's your responsibility to experiment with these frameworks and find the right ones for your team's needs.

Remember, there are no silver bullet frameworks. Every company, team, and product are unique. How in the world can there be one solution to rule them all?!   

Here are a couple of my favorite problems, and the frameworks we implemented in response.

  • Overloaded use of the word "team".  I lost days off of my life, clarifying what someone means when they say "my team".  That same person is on a scrum team, the database team, and the software engineering team.  The waste of clarifying which team we were talking about drove me crazy!  Enter Spotify.  We used their model to develop a logical, scalable nomenclature for everyone to use.  
  • What does a great team look like?  Asking a team to get better without providing a definition of what "better" looks like is a common problem.  That's no different than a sports coach telling a player to "do better next time" without providing them guidance on what they are doing wrong.  All of my new teams read two books to form a common understanding of what a great team looks like and how they can operate to deliver on that goal of greatness.
    • We start with Debugging Teams as our tool for educating everyone on what greatness looks like.  Once we are all on the same page with the destination, we start mapping out a plan of how we get there.
    • Crucial Conversations arms the team with a framework for how they can help each other achieve greatness.  With a framework in place teammates become more receptive to coaching and feedback by providing everyone with a common set of tools to create safe, effective conversations.
  • Architectural ivory towers.  How can someone that doesn't "do the job" every day actually know what is best for a group of practitioners?  I'll make it simple for you.  They can't.  We implemented a version of "Chapters" from Spotify.  These loosely coupled groups of engineers partnered with our architect to continuously refine our products and its underlying infrastructure.  Was it easy for our architect?  No way.  It flipped his world upside down, but this model enabled our team to scale without him becoming overburdened.  He was able to support our growing team and didn't have to have all of the answer all of the time.
I'll dig deeper into each of those topics (and many more) in future posts, but the key is being intentional about the use of frameworks to solve more than problems with 1s and 0s. Look around with your framework lens, and you'll be surprised how many you find...

Enable & empower

Trust. A simple concept, but seldom executed well.

I always equate the trust you have with your team as a bank account. Others use that analogy to draw a comparison to how easily it is to lose trust vs gain it. I prefer to use it as an example that you must extend trust first. After all, a bank account without an initial deposit is useless.

Most employees bring some baggage from their past. That baggage is usually weighed down by a mistrust for management because of how their previous companies operated. This baggage is your toughest enemy in growing trust, but having awareness that it exists is your secret weapon.

So what can you do?

  1. Don't try for a big win.  I've seen leaders try to gain the favor of their team with a big, one-time event.  The shine of that moment wears off quicker than you think.  Slow and steady wins this race.  Your team will know you trust them, when you operate consistently. That's what trust is.  They know you will operate the same way, even when the chips are stacked against you and your team.
  2. Don't be soft.  Building trust doesn't mean agreeing with everything the team wants.  A coach that always agrees with you and never pushes you isn't really a coach.  Your team wants to get better, and that comes with being challenged to grow beyond who they currently are.  That growth isn't easy and needs both your support and some challenging from you.  Remember, self-directed doesn't mean leadership is asleep at the wheel.  Your job is to lead!
  3. Only speak in questions.  You're in this position because you were right, a lot.  That means you've seen hundreds of crazy scenarios and made a million mistakes.  With all of that experience in your back pocket, your first instinct will be to deliver the answer to your team.  That get's them moving on to the next work item as fast as possible.  What did they learn?  How will they handle that scenario if you are on vacation on in some crazy, all day meeting?  Even when you know the answer, ask questions.  Lead the team to the best answer by helping them discover it.  Don't give it to them.

Build a commercial mindset

Building great software is hard. It's even harder when you don't really know how your project affects the customer or the company's bottom line. How can you make sure the million micro-decisions that happen in a software project are the best ones for those two factors if the team only has a cursory understanding of the customer and the business model?

Partner with the product team, in whatever capacity you can, to continuously educate the team on the "why" behind decisions. Why is this epic ranked higher than that other epic? Why do we bill our customers annually instead of monthly? There are a million other "why" questions that must be answered to build the deep commercial mindset in your team.

  • Host lunch and learns, with other departments across the company.  
  • Use every ceremony as an opportunity to educate.  
  • Fill in the understanding gaps with a quick, 5 minute explanation of a key decision. 
  • Get your engineers out in "the field".

Just as asking only questions builds your teams capability and capacity to find the right solution on their own, having a commercial mindset empowers them to make the best micro-decisions possible for your company and your customers.

Wrapping up

I'm passionate about this topic, so expect more and more content around this. In the meantime, dig into some of our Meta-Cast episodes centered on leadership. They will give you more insight into many of these topics. If you are really excited to learn more, reach out to us and we'll help you build the team(s) of your dreams.

All Posts

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!