Overview

I’d like to talk about something near and dear to my heart.  Something that I believe many technology leaders who are trying to build a world-class team would agree with.  Something that may be abundantly  obvious, but there is no one reason as to why.  Ready for this earth-shattering statement?  “Building a GOOD Software organization is REALLY HARD!”.

Isn’t this obnoxiously obvious?  But have you asked why it’s so hard? Have you asked yourself, what are the impediments and challenges that makes it so difficult?  The answer is much more subtle yet, more complicated and involved than one might think.  More often than not, the answer rarely has much to do with the technology. Although it plays a role, and yes “Software is hard”, but that warrants a series in itself, stay tuned for that. Instead, it has much more to do with all the unsexy pieces that must fall in to place to support the successful delivery of your product.  Yes, I am talking about creating the right team, at the right size, at the right time, with the right process.

Through my career, I have had my fair share of challenges building teams of various sizes in various environments, some successful, some not so much.  In this series (as one article will not cover all the mistakes I have made), I will discuss some of the challenges, lessons, and observations I have come across while trying to build great software teams. As I am a software architect at heart, most of my experience is in building software organizations and the teams that enable them, I will also discuss how some challenges may be mitigated by applying good, sound architectural patterns and practices.

In this series, I will be going through the following topics:

1. Leading with Empathy
2. People over process, the Agile way
3. A good and flexible Architecture ACTUALLY matters
4. DevOps … NOT just about tools
5. The RIGHT team at the RIGHT time 

In this first post, we discuss what I believe to be one of the most important traits in order to affect change as a technology leader. Spoiler alert, it is NOT ruling with an iron fist.  It’s also not about how smart you are or how much you know (although relevant experience and knowledge certainly helps). It’s about leading with empathy and connecting with others within your organization IN ORDER TO truly understand what their pain points are, and conversely, what their strengths are.  It’s about understanding the culture and having the empathy to navigate that culture to positively affect changes from the inside out.

Leading with Empathy

In order to build a well-oiled engineering team, a leader must first understand the limitations that an organization may impose on the team or department.  In other words, if you come into an organization that has been primarily operating under a waterfall methodology, and try to shove Agile into the mix, it will not matter how smart your Engineers are, you are bound to make some enemies along a very arduous path wrought with pain and suffering … sound familiar anyone?

Many organizations, whether they know it or not, reflect the challenges of “Conway’s Law”, which states:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin E. Conway (Wikipedia)

Stated a different way, your organizations’ engineering teams, and the software they are building, WILL reflect the organizations hierarchy and communication style.  I will not be going deep into Conway’s law as there are enough articles online about this, but suffice to say, this is at the heart of understanding why teams may be operating the way they are.  An example here is warranted.

Let’s say you are working with a company who has a deep hierarchical tree, divided by technical functional areas to improve efficiency  (front end, backend, DevOps, Data, Business Analysts, etc.),  This type of organizational will likely yield teams that will build a monolithic architecture with tight coupling between components due to the fast and easy nature of communicating with your counterparts on your own functional team, and integrating with the other functional areas via whatever agreed upon contractual interface.

Now of course, this is NOT a bad thing, as it truly depends on what you are trying to build.  However, as your product becomes more successful and demands grow, inevitably complexity will grow, and strong coupling could lead to code that is hard to maintain, fragility, red tape to make simple changes, etc..  The next logical step for a leader might be to grow the team to meet the heavy demands and increased workload and complexity.  However, adding more people will only exacerbate the problem.  You might be tempted to hire a rockstar architect to oversee the entire application, however that individual, while great, will also be met with the same challenges of communication that follows functional team silos.  You might then be tempted to start changing the structure of the teams so that you have disciplines within the teams (i.e. feature teams).  But then you are met with organizational challenges, because the organization simply does not operate well with cross discipline teams (who is the front-end developer going to report to?  The Feature team lead?  But the front-end developers’ boss is the front-end Lead … hmmm).

You see, while your ideas and execution are correct, if the organizational culture is not ready to accept that change, you are fighting an uphill battle.  So how do you overcome this?  Here are a few tips that can get you started:

1. KNOW THAT THIS IS A GOOD problem to have:  If the organization was not growing, you would not have to grow with it, and thus would not have this challenge
2. The Organization is growing!  If you’re at this point, it means that the organization has been growing by the great work the team(s) have done.  I cannot overstate this enough … you MUST KNOW that the teams have done a great job to get the organization to where they are at now, and that must not be overlooked.  The organization is now simply hitting a scale that will require change to be even more successful in the future … this is where you come in.
3. People come FIRST: Get to know all the different teams members within the organization and understand their pain points, their struggles, and their strengths. Spend time getting to know them at a personal level.  Understand what makes them tick, what they love, what settings allow them to thrive, etc.  It is only when you understand them, that you can affect positive change that will be beneficial to each individual, and subsequently, the team.  However, you must do this with a genuine interest in the individual FIRST, before anything else, without ulterior motives.  Only then will you be able to clearly see what pieces to move where to construct a team that is mutually beneficial for the person, the team, and thus, the organization.
4. Know the leadership:  Get to know leadership and understand their roadmap for the future.  Understand  where they have been successful in implementing their vision, and understand where they have fallen short.  Understand their constraints and their degrees of freedmon.  This understanding coupled with knowing the implementation team, will give you a clear view of the chess board, and help you strategize WITH the leadership team, what moves you might need to make next.
5. Educate and collaborate:  Educate teams and leadership on WHY you are suggesting the changes, and help them see how these changes not only benefit them, but how they fit into the overall vision for their organization.  Allow the teams to educate YOU by bringing the teams into the conversations to potentially shed light on your blind spots.  Allow the teams to provide input and to help shape the future.  Build a community of trust and collaboration.
6. Change starts small:  Identify opportunities within the teams where you might be able to make incremental changes, but not completely change the dynamics of the culture.  In our example above, a great first step could involve inviting members of the front-end team to join a back-end team design meeting.  Invite the front-end engineers to ask questions, or weigh in on the topics being discussed, while you facilitate the discussions.  The goal here is to encourage cross-function collaboration.
7. BE PATIENT:  This is going to be hard.  Be patient, kind, humble, and empathetic.  Encourage others to do the same.  Some discussions may not yield the exact outcome you plan, but embrace agility, and “go with the flow”.

Notice that the steps above revolve around empathy and understanding.  As you understand and apply empathy, you will start to see why things operate in a certain way, and from there try to affect positive change at the root.

Leading with empathy will establish your credibility, and equip you with the appropriate influence to promote change to start building a well-oiled engineering team.  This is just the beginning.  In the next post in this series, we will discuss the second component that helps create a well-oiled engineering team: “People over Process, the Agile way“.

Stay tuned!