Our Week 2 module included a Google video entitled \u201cThe Myth of the Genius Programmer,\u201d which really resonated with me and I found myself still thinking back to it this week. \u00a0The 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.\u00a0 The conclusion from this revelation is that being able to improve a team\u2019s performance is actually a more important skill for success than extraordinary individual talent.<\/p>\n\n\n\n
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.\u00a0 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.\u00a0 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.<\/p>\n\n\n\n
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.\u00a0 Unfortunately, in their zeal to drive progress, raise issues or even just appear relevant, managers often take actions which perpetuate a team\u2019s discomfort with working in a humble and transparent manner.<\/p>\n\n\n\n
The Great Experiment<\/strong><\/p>\n\n\n\n For the past several years I have worked for one of the large tech companies which is known for stressing results.\u00a0 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\u2019s initial preferences).<\/p>\n\n\n\n I didn\u2019t employ any magic formula, but mostly it came down to being trustworthy and transparent.\u00a0 Following are a few principles which I would consider to be key.<\/p>\n\n\n\n Use commitments fairly<\/em><\/strong><\/p>\n\n\n\n Even skilled, knowledgeable professionals may have difficulty projecting how long a task which is new to them will take to complete.\u00a0 This is particularly true in software development, where most tasks are somewhat unique and problems can be difficult to anticipate.\u00a0 As a result, well intending developers regularly discover that estimates which they shared in good faith are actually unachievable.<\/p>\n\n\n\n In contrast, program\/project managers tend to favor certitude, which creates tension when planning is necessarily based on inexact inputs.\u00a0 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.\u00a0 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).<\/p>\n\n\n\n Be transparent<\/em><\/strong><\/p>\n\n\n\n In all aspects, it is important for a team leader to exhibit the behavior that (s)he wants to the team to adopt.\u00a0 This is particularly true with regard to transparency.\u00a0 In any team, I always make a point to air any problems, issues or mistakes as openly as I possibly can.\u00a0 I have heard a few opinions that this \u201clowers the bar\u201d 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.\u00a0 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.<\/p>\n\n\n\n Ask dumb questions<\/em><\/strong><\/p>\n\n\n\n Much of what I just said about transparency applies to this point also.\u00a0 Most people don\u2019t 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.\u00a0 As such I always make a point to ask some fairly elementary questions that I think I already know the answer to.\u00a0 These are mostly tailored to ensure that everyone on the team hears the answers and has an aligned understanding of the problem at hand.\u00a0 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.<\/p>\n\n\n\n Be positive and focus on solutions<\/em><\/strong><\/p>\n\n\n\n Most people want to work in a positive, collaborative environment to find solutions to problems.\u00a0 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.\u00a0 One of the best ways to avoid this mentality is to always focus the conversation on solutions.\u00a0 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.\u00a0 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.<\/p>\n\n\n\n Recognize achievement<\/em><\/strong><\/p>\n\n\n\n It seems simple, but many managers fail to recognize the achievements of the team and its members.\u00a0 This recognition is important, particularly in that it also demonstrates the importance of stakeholder(s) success.\u00a0 Where possible, I tend to communicate failures as a team failure without calling out specific individuals to an outside audience.<\/p>\n\n\n\n Results of the Great Experiment<\/strong><\/p>\n\n\n\n Overall, results exceeded my expectation.\u00a0 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.\u00a0 However, after a few weeks, virtually everyone embraced the approach enthusiastically.\u00a0 Meetings took on a super-positive and supportive tone in which people stopped blaming other stakeholders for issues and focused on solutions.\u00a0 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.\u00a0 People were no longer concerned about taking a calculated risk of failure and when a test didn\u2019t work out, the entire team would have a good-natured laugh together then immediately fly into finding a solution.<\/p>\n\n\n\n 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.\u00a0 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.\u00a0 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.<\/p>\n\n\n\n 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.\u00a0 In the short term this resulted in more aggressive schedule plans, but no improvement to actual delivery.\u00a0 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. \u00a0Which brings me back to my original point\u2026 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.<\/p>\n","protected":false},"excerpt":{"rendered":" Our Week 2 module included a Google video entitled \u201cThe Myth of the Genius Programmer,\u201d which really resonated with me and I found myself still thinking back to it this week. \u00a0The key underlying tenant of the discussion was that epic achievements in software development tends to result from the collaboration of high-functioning teams rather […]<\/p>\n","protected":false},"author":11946,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-23","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/posts\/23","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/users\/11946"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/comments?post=23"}],"version-history":[{"count":2,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/posts\/23\/revisions"}],"predecessor-version":[{"id":25,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/posts\/23\/revisions\/25"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/media?parent=23"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/categories?post=23"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/carltjoh\/wp-json\/wp\/v2\/tags?post=23"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}