The Carlton Dance

Our Week 2 module included a Google video entitled “The Myth of the Genius Programmer,” which really resonated with me and I found myself still thinking back to it this week.  The key underlying tenant of the discussion was that epic achievements in software development tends to result from the collaboration of high-functioning teams rather than the genius of a single individual working in isolation.  The conclusion from this revelation is that being able to improve a team’s performance is actually a more important skill for success than extraordinary individual talent.

By extension, the speakers also discussed that failure and learning are natural parts of the development process, and therefore developers should embrace and plan for both.  Personally, I could not agree more, but I would argue that persuading leadership to provide an environment in which such behavior can flourish is often the bigger challenge.  This can be particularly challenging in the context of a large organization where perverse incentives may persuade managers to act in a manner which is inconsistent with the goal of providing a healthy environment for development.

Failed tests, mistakes and questions which demonstrate a lack of knowledge are all important parts of the development process, and although concerns which prevent such behavior may represent impediments to progress, that does not mean that the concerns are unfounded.  Unfortunately, in their zeal to drive progress, raise issues or even just appear relevant, managers often take actions which perpetuate a team’s discomfort with working in a humble and transparent manner.

The Great Experiment

For the past several years I have worked for one of the large tech companies which is known for stressing results.  After repeatedly encountering teams which were reserved and risk averse, I decided to focus on providing my team the kind of environment in which I would like to work and in which I would feel free to perform my best work (although this required some steps which were not consistent with my own leadership’s initial preferences).

I didn’t employ any magic formula, but mostly it came down to being trustworthy and transparent.  Following are a few principles which I would consider to be key.

Use commitments fairly

Even skilled, knowledgeable professionals may have difficulty projecting how long a task which is new to them will take to complete.  This is particularly true in software development, where most tasks are somewhat unique and problems can be difficult to anticipate.  As a result, well intending developers regularly discover that estimates which they shared in good faith are actually unachievable.

In contrast, program/project managers tend to favor certitude, which creates tension when planning is necessarily based on inexact inputs.  Unfortunately, there is a commonly repeated pattern in which program/project managers insist on team members providing schedule estimates, challenge any estimates they believe to not be aggressive enough, and then cite any miss as a failure, indicative of poor performance.  Honest and transparent communication within a team is important, but can only be achieved if commitments are treated fairly (such as not over-representing the strength of commitments from stakeholders).

Be transparent

In all aspects, it is important for a team leader to exhibit the behavior that (s)he wants to the team to adopt.  This is particularly true with regard to transparency.  In any team, I always make a point to air any problems, issues or mistakes as openly as I possibly can.  I have heard a few opinions that this “lowers the bar” by making stakeholders comfortable with a lower level of achievement, but in my experience, this is only the case if you have hired the wrong people.  In my experience, most people want to succeed together, but the reality is that things do not always go smoothly and it is important to set the tone for a team to share such things openly without fear of judgement.

Ask dumb questions

Much of what I just said about transparency applies to this point also.  Most people don’t enjoy the appearance of ignorance, yet when working on something new, it is completely normal to not have a high level of knowledge about some of the subject matter.  As such I always make a point to ask some fairly elementary questions that I think I already know the answer to.  These are mostly tailored to ensure that everyone on the team hears the answers and has an aligned understanding of the problem at hand.  These types of questions also set a tone which makes it more comfortable for other stakeholders to raise questions they might otherwise find embarrassing, and with fair regularity I receive an unexpected answer which refines or corrects my understanding of the topic.

Be positive and focus on solutions

Most people want to work in a positive, collaborative environment to find solutions to problems.  However, organizational pressures can tempt otherwise well-intended people to become harsh, critical or blamey, particularly when they themselves are uncomfortable or self-conscious about some issue.  One of the best ways to avoid this mentality is to always focus the conversation on solutions.  Discussion of mistakes or failures is only productive to the extent that it provides some learning which helps us understand the problem to be solved.  When people are confident that they will not be attacked for missteps, they tend to surface problems faster so that the entire team can work on them and they waste less time on trying to defend themselves.

Recognize achievement

It seems simple, but many managers fail to recognize the achievements of the team and its members.  This recognition is important, particularly in that it also demonstrates the importance of stakeholder(s) success.  Where possible, I tend to communicate failures as a team failure without calling out specific individuals to an outside audience.

Results of the Great Experiment

Overall, results exceeded my expectation.  Initially team members seemed surprised or even suspicious when I introduced a way of working together which was different from what they had seen previously.  However, after a few weeks, virtually everyone embraced the approach enthusiastically.  Meetings took on a super-positive and supportive tone in which people stopped blaming other stakeholders for issues and focused on solutions.  Everyone on the team felt a strong sense of support from each other, with the result that missteps and problems (even those which might be embarrassing in a more typical environment) came to the forefront almost eagerly.  People were no longer concerned about taking a calculated risk of failure and when a test didn’t work out, the entire team would have a good-natured laugh together then immediately fly into finding a solution.

Although it is difficult to provide a specific metric, I did note that initiatives were completed faster and with fewer misses once the team had embraced the open style of collaboration.  In one case, the team delivered a key strategic win which leadership had assessed had less than a two percent probability of success at the outset.  More importantly to me, people were free to deliver their best work with joy, and our team became one that people tended to gravitate to.

However, if I am totally honest about the results, I also have to note that our leadership decided that although the team was functioning at a very high level, we could get more out of them by taking a tougher stance to hold people accountable.  In the short term this resulted in more aggressive schedule plans, but no improvement to actual delivery.  In the longer term, this resulted in a loss of trust and a return to a mode of work resembled what it had been before I took over the team.  Which brings me back to my original point… it is great to instill an appreciation for transparency and openness in developers, but this will only succeed if we also provide an environment in which people are allowed to work in such a manner and flourish by doing so.