🗄️Data Management: Data Governance (Part III: Taming the Complexity)

Data Management Series

The Chief Data Officer (CDO) or the “Head of the Data Team” is one of the most challenging jobs because is more of a "political" than a technical role. It requires the ideal candidate to be able to throw and catch curved balls almost all the time, and one must be able to play ball with all the parties having an interest in data (aka stakeholders). It’s a full-time job that requires the combination of management and technical skillsets, and both are important! The focus will change occasionally in one direction more than in the other, with important fluctuations. 

Moreover, even if one masters the technical and managerial aspects, the combination of the two gives birth to situations that require further expertise – applied systems thinking being probably the most important. This, also because there are so many points of failure that it's challenging to address all the important causes. Therefore, it’s critical to be a system thinker, to have an experienced team and make use adequately of its experience! 

In a complex word, in which even the smallest constraint or opportunity can have an important impact especially when it’s involved in the early stages of the processes taking place in organizations. It relies on the manager’s and team’s skillset, their inspiration, the way the business reacts to the tasks involved and probably many other aspects that make things work. It takes considerable effort until the whole mechanism works, and even more time to make things work efficiently. The best metaphor is probably the one of a small combat team in which everybody has their place and skillset in the mechanism, independently if one talks about strategy, tactics or operations. 

Unfortunately, building such teams takes time, and the more people are involved, the more complex this endeavor becomes. The manager and the team must meet somewhere in the middle in what concerns the philosophy, the execution of the various endeavors, the way of working together to achieve the same goals. There are multiple forces pulling in all directions and it takes time until one can align the goals, respectively the effort. 

The most challenging forces are the ones between the business and the data team, respectively the business and data requirements, forces that don’t necessarily converge. Working in small organizations, the two parties have in theory more challenges to overcome the challenges and a team’s experience can weight a lot in the process, though as soon the scale changes, the number of challenges to be overcome changes exponentially (there are however different exponential functions in which the basis and exponent make the growth rapid). 

In big organizations can appear other parties that have the same force to pull the weight in one direction or another. Thus, the political aspects become more complex to the degree that the technologies must follow the political decisions, with all the positive and negative implications deriving from this. As comparison, think about the challenges from moving from two to three or more moving bodies orbiting each other, resulting in a chaotic dynamical system for most initial conditions. 

Of course, a business’ context doesn’t have to create such complexity, though when things are unchecked, when delays in decision-making as well as other typical events occur, when there’s no structure, strategy, coordinated effort, or any other important components, the chances for chaotic behavior are quite high with the pass of time. This is just a model to explain real life situations that seem similar on the surface but prove to be quite complex when diving deeper. That’s probably why a CDO’s role as tamer of complexity is important and challenging!

Previous Post <<||>> Next Post

Data Science: Data Strategy (Part II: Generalists vs Specialists in the Field)

Division of labor favorizes the tasks done repeatedly, where knowledge of the broader processes is not needed, where aspects as creativity are needed only at a small scale. Division invaded the IT domains as tools, methodologies and demands increased in complexity, and therefore Data Science and BI/Analytics make no exception from this.

The scale of this development gains sometimes humorous expectations or misbelieves when one hears headhunters asking potential candidates whether they are upfront or backend experts when a good understanding of both aspects is needed for providing adequate results. The development gains tragicomical implications when one is limited in action only to a given area despite the extended expertise, or when a generalist seems to step on the feet of specialists, sometimes from the right entitled reasons. 

Headhunters’ behavior is rooted maybe in the poor understanding of the domain of expertise and implications of the job descriptions. It’s hard to understand how people sustain of having knowledge about a domain just because they heard the words flying around and got some glimpse of the connotations associated with the words. Unfortunately, this is extended to management and further in the business environment, with all the implications deriving from it. 

As Data Science finds itself at the intersection between Artificial Intelligence, Data Mining, Machine Learning, Neurocomputing, Pattern Recognition, Statistics and Data Processing, the center of gravity is hard to determine. One way of dealing with the unknown is requiring candidates to have a few years of trackable experience in the respective fields or in the use of a few tools considered as important in the respective domains. Of course, the usage of tools and techniques is important, though it’s a big difference between using a tool and understanding the how, when, why, where, in which ways and by what means a tool can be used effectively to create value. This can be gained only when one’s exposed to different business scenarios across industries and is a tough thing to demand from a profession found in its baby steps. 

Moreover, being a good data scientist involves having a deep insight into the businesses, being able to understand data and the demands associated with data – the various qualitative and quantitative aspects. Seeing the big picture is important in defining, approaching and solving problems. The more one is exposed to different techniques and business scenarios, with right understanding and some problem-solving skillset one can transpose and solve problems across domains. However, the generalist will find his limitations as soon a certain depth is reached, and the collaboration with a specialist is then required. A good collaboration between generalists and specialists is important in complex projects which overreach the boundaries of one person’s knowledge and skillset. 

Complexity is addressed when one can focus on the important characteristic of the problem, respectively when the models built can reflect the demands. The most important skillset besides the use of technical tools is the ability to model problems and root the respective problems into data, to elaborate theories and check them against reality. 

Complex problems can require specialization in certain fields, though seldom one problem is dependent only on one aspect of the business, as problems occur in overreaching contexts that span sometimes the borders of an organization. In addition, the ability to solve problems seem to be impacted by the diversity of the people involved into the task, sometimes even with backgrounds not directly related to organization’s activity. As in evolution, a team’s diversity is an important factor in achievement and learning, most gain being obtained when knowledge gets shared and harnessed beyond the borders of teams.

Note:
Written as answer to a Medium post on Data Science generalists vs specialists.

💼Project Management: Methodologies (Part IV: Agility under Eyeglasses II)

Continuation

Employees are used to follow procedures and processes, and when they aren’t available insecurity rules - each day there’s another idea advanced how things are supposed to work. Practically, the Agile approaches (incl. Agile Prince2) focus on certain aspects and ignore specific Project Management activities that need to be performed inside of a project – releasing resources for the project, getting users on-board, getting management’s buy-in, etc. Therefore, they need to be used with a methodology that offers the lacking processes. Problematic is when is considered that the Agile approaches are self-consistent and the Project Management practices and principles don’t apply anymore.

It’s true that the Agile methods attempt reconciling disciplined project execution with creativity and innovation, however innovation is needed typically in design (incl. prototyping) , while in programing there isn’t lot of room for creativity per se. The real innovation appears when the customer lists the functionality it needs from a system and the vendor, after analyzing all the related requirements, is capable to evaluate and propose a solution from the industry trending technologies. That’s innovation and not changing controls in user interfaces!

User stories are good for situations in which an organization doesn’t know what’s doing or the tasks have a deep segmentation and specialization. Starting from user stories and building upwards to processes can prove to be a waste of time the customer pays for, while the approach leaves few room for innovation. In big projects it’s also difficult to sense the contradictions from user stories or their duplication. Even if the user stories allow maybe (but not necessarily) a better effort estimate the level of detail can become overwhelming for any skilled solution architect.

It’s also true that an agile approach needs a culture with certain characteristics. A culture can’t be changed with one project or several projects running in parallel. Typically, is recommended to start with a pilot test, assert organization’s readiness, disseminate knowledge, start several small to medium projects and build from there. For sure starting a big project with an agile methodology  will involve more challenges to the extent the challenges will push back.

One sign of agility is when self-organizing teams emerge within projects, however it takes time and training to build such teams. The seeds must be planted long before, for such teams to emerge. The key is being able of working in such teams. In extremis, conflicts appear when multiple self-organizing teams appear, each with its own political agenda, agendas that don’t necessarily match project manager or stakeholders’ agendas, and from here a large range of potential conflicts.

The psychological effect of tight sprints (iterations) and daily status meetings for the whole duration of a project is not to neglect. It builds unnecessary stress and, unless the planning reaches perfection, the programmer or consultant will often find himself in the position to be in defensive. The frequent meetings can easily become a source for nuisance and in extremis can lead to extreme behavior that can easily affect the productivity and involved persons’ health.

Personally, I wouldn’t recommend using an Agile methodology for a big project like an ERP implementation unless it was adequately adapted to organization’s needs. This doesn’t necessarily mean that the Agile methods aren’t suitable for big projects, it means that the risks are high because in big projects there’s the chance for all these mentioned issues to occur.

Despite the weak points of the Agile methods, when adequately applied, they have the chance of better performing than the “traditional” approaches. Even if people tend to see more the negative sides there’s lot of potential in being agile.

Previous Post <<||>>Next Post

✨Performance Management: Teams [Sports] (Just the Quotes)

"A team divided against itself can break down at any moment. The least bit of pressure or adversity will crack it apart." (Bill Parcells, "Finding a Way to Win: The Principles of Leadership, Teamwork, and Motivation", 1995)

"Bringing together disparate personalities to form a team is like a jigsaw puzzle. You have to ask yourself: what is the whole picture here? We want to make sure our players all fit together properly and complement each other, so that we don't have a big piece, a little piece, an oblong piece, and a round piece. If personalities work against each other, as a team you'll find yourselves spinning your wheels." (Pat Summitt, "Reach for the Summit", 1999)

"Never set a goal that involves number of wins - never. Set goals that revolve around playing together as a team. Doing so will put you in a position to win every game." (Mike Krzyzewski, "Leading with the Heart", 2000)

"In putting together your standards, remember that it is essential to involve your entire team. Standards are not rules issued by the boss; they are a collective identity. Remember, standards are the things that you do all the time and the things for which you hold one another accountable." (Mike Krzyzewski, "The Gold Standard: Building a World-Class Team", 2009)

"A leader may be the most knowledgeable person in the world, but if the players on his team cannot translate that knowledge into action, it means nothing."  (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"Encourage members of your team to take the initiative and act on their own." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"Goals should be realistic, attainable, and shared among all members of the team." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"If a team cannot perform with excellence at a moment's notice, they probably will fail in the long run." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"In leadership, there are no words more important than trust. In any organization, trust must be developed among every member of the team if success is going to be achieved." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"Leaders have to search for the heart on a team, because the person who has it can bring out the best in everybody else." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"Mutual commitment helps overcome the fear of failure - especially when people are part of a team sharing and achieving goals. It also sets the stage for open dialogue and honest conversation." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"People want to be on a team. They want to be part of something bigger than themselves. They want to be in a situation where they feel that they are doing something for the greater good." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"There are five fundamental qualities that make every team great: communication, trust, collective responsibility, caring and pride. I like to think of each as a separate finger on the fist. Any one individually is important. But all of them together are unbeatable." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"When you first assemble a group, it's not a team right off the bat. It's only a collection of individuals." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"You develop a team to achieve what one person cannot accomplish alone. All of us alone are weaker, by far, than if all of us are together." (Mike Krzyzewski, "Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life", 2010)

"In climbing, having confidence in your partners is no small concern. One climber's actions can affect the welfare of the entire team." (Jon Krakauer, "Into Thin Air: A personal account of the Everest disaster", 2011)

"Basketball is a great mystery. You can do everything right. You can have the perfect mix of talent and the best system of offense in the game. You can devise a foolproof defensive strategy and prepare your players for every possible eventuality. But if the players don't have a sense of oneness as a group, your efforts won't pay off. And the bond that unites a team can be so fragile, so elusive." (Phil Jackson, "Eleven Rings", 2015)

✨Performance Management: Teams (Just the Quotes)

"A few honest men are better than numbers." (Oliver Cromwell, [Letter to William Spring], 1643)

"The man who goes alone can start today; but he who travels with another must wait till that other is ready." (Henry D Thoreau, Walden, 1854)

"It is the lone worker who makes the first advance in a subject: the details may be worked out by a team, but the prime idea is due to the enterprise, thought and perception of an individual." (Alexander Fleming, [Address at Edinburgh University] 1951)

"Top management work is work for a team rather than one man." (Peter F Drucker, "Memos for Management: Leadership", 1983)

"Teamwork is consciously espoused but unwittingly shunned by most people in business because they are deathly afraid of it. They think it will render them anonymous, invisible." (Srully Blotnick, "The Corporate Steeplechase", 1984)

"The whittling away of middle management is further reinforcing the trend for companies to smash the hierarchical pyramid and adopt new people structures such as networks, intrapreneurs, and small teams." (John Naisbett & Patricia Aburdene, "Re-inventing the Corporation", 1985)

"Teams are less likely [than individuals] to overlook key issues and problems or take the wrong actions." (Eugene Raudsepp, MTS Digest, 1987)

"The manager must decide what type of group is wanted. If cooperation, teamwork, and synergy really matter, then one aims for high task interdependence. One structures the jobs of group members so that they have to interact frequently [...] to get their jobs done. Important outcomes are made dependent on group performance. The outcomes are distributed equally. If frenzied, independent activity is the goal, then one aims for low task interdependence and large rewards are distributed competitively and unequally." (Gregory P Shea & Richard A Guzzo, Sloan Management Review, 1987)

"We know we need better teamwork; the question is how to achieve it. Very few people defend the adversarial relationship, but no one has a clear idea of how to do away with it. The usual method is exhortation. But this approach has failed us time and time again." (Robert F Daniell, Harvard Business Review, 1987)

"Managing requires setting aside one's ego to encourage and develop the work of others. It requires a 'big picture' and team perspective rather than an individual-achiever perspective." (Sara M Brown, 1988)

"When a team outgrows individual performance and learns team confidence, excellence becomes a reality." (Joe Paterno, American Heritage, 1988)

"Complacency is the last hurdle standing between any team and its potential greatness." (Pat Riley, "Winner Within Success", 1993)

"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)

"Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively." (Steve McConnell, "Software Project Survival Guide", 1997)

"We think most process initiatives are silly. Well-intentioned managers and teams get so wrapped up in executing processes that they forget that they are being paid for results, not process execution. (Peter Coad et al, "Java Modeling in Color with UML", 1999)

"The business changes. The technology changes. The team changes. The team members change. The problem isn't change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes." (Kent Beck, "Extreme Programming Explained", 2000)

"A well-functioning team of adequate people will complete a project almost regardless of the process or technology they are asked to use (although the process and technology may help or hinder them along the way)." (Alistair Cockburn, "Agile Software Development", 2001)

"Team leaders have to connect with their team and themselves. If they don't know their team's strengths and weaknesses, they cannot hand off responsibilities to the team. And if they don't know their own strengths and weaknesses, they will not hand off responsibilities to the team." (John C Maxwell, "Teamwork Makes the Dream Work", 2002)

"Good bosses provide a constant flow of clear and concise information and encourage you and the rest of your team to do the same." (John Hoover, "How to Work for an Idiot", 2004)

"On a team, trust is all about vulnerability, which is difficult for most people." (Patrick Lencioni, "The Five Dysfunctions of a Team: Participant Workbook", 2007)

"Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Mission is at the heart of what you do as a team. Goals are merely steps to its achievement." (Patrick Dixon, "Building a Better Business", 2005)

"The facts are in: diverse companies and teams consistently outperform all others. It's not only the smart thing and the right thing, it makes getting the job done much more interesting." (Marilyn C Nelson, "How We Lead Matters: Reflections on a Life of Leadership", 2008)

"Teams should be able to act with the same unity of purpose and focus as a well-motivated individual." (Bill Gates, "Business @ the Speed of Thought: Succeeding in the Digital Economy", 2009)

"If your team is filled with people who work for the company, you'll soon be defeated by tribes of people who work for a cause." (Seth Godin, "The Icarus Deception: How High Will You Fly?", 2012)

"Ultimately, leadership is not about glorious crowning acts. It's about keeping your team focused on a goal and motivated to do their best to achieve it, especially when the stakes are high and the consequences really matter. It is about laying the groundwork for others' success, and then standing back and letting them shine." (Chris Hadfield, "An Astronaut's Guide to Life on Earth", 2013)

"A software team can get severely constrained when a velocity target is imposed on it. Velocity works well as a measurement, not as a target. Targets limit choice of actions. A team may find itself unable to address technical debt if it is constrained by velocity targets. At a certain threshold of constraints, team members lose the sense of empowerment (autonomy)." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Although essential, governance is an activity, not an outcome. This makes it risky to grant autonomy to a pure governance team. Instead, it is better to constitute each area of governance as a community of practice consisting of practitioners from various capability teams." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"In order to control where a team devotes its energies, all you need to do is to impose a bunch of targets and track progress at regular intervals. For greater control, increase the range of targets and track more frequently. This is called micromanagement and is universally detested by teams. Doing so increases reporting overhead but rarely improves team performance." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Self-organizing teams need autonomy. […] Autonomy allows us to act on the opportunity that purpose provides. Mastery then lets us service the opportunity with a degree of excellence. Targets distort purpose, limit autonomy, and disregard mastery." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Teams motivated by targets tend not to take ownership of problems. They attend only to those aspects that affect targets and leave the rest to be picked up by someone else. To some extent, the problem isn’t the target itself but rather the incentive behind the target." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Whatever way we organize, the unit of organization is a team, and any team can turn into a silo if it acts in an insular manner. Therefore, in a sense, we can’t eliminate silos but only try to design around their side effects." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"The higher the price of information in a software team, the less effective the team is." (Yegor Bugayenko, "Code Ahead", 2018)

"To make technical decisions, a result-oriented team needs a strong architect and a decision making process, not meetings." (Yegor Bugayenko, "Code Ahead", 2018)

"A 'stream' is the continuous flow of work aligned to a business domain or organizational capability. Continuous flow requires clarity of purpose and responsibility so that multiple teams can coexist, each with their own flow of work. A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Organizations that rely too heavily on org charts and matrixes to split and control work often fail to create the necessary conditions to embrace innovation while still delivering at a fast pace. In order to succeed at that, organizations need stable teams and effective team patterns and interactions. They need to invest in empowered, skilled teams as the foundation for agility and adaptability. To stay alive in ever more competitive markets, organizations need teams and people who are able to sense when context changes and evolve accordingly." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Teams take time to form and be effective. Typically, a team can take from two weeks to three months or more to become a cohesive unit. When (or if) a team reaches that special state, it can be many times more effective than individuals alone. If it takes three months for a team to become highly effective, we need to provide stability around and within the team to allow them to reach that level." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"The culture of your organization comprises your stated principles, and to a far greater extent, the actual lived principles as reflected by the attitudes, communication styles, and behaviors of your teams." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)

"One of the great enemies of design is when systems or objects become more complex than a person - or even a team of people - can keep in their heads. This is why software is generally beneath contempt." (Bran Ferren)

🌡️Performance Management: Feedback (Definitions)

"The return of information about the status of a process. Example: annual performance reviews return information to an employee about the quality of his or her work." (Virginia Anderson & Lauren Johnson, "Systems Thinking Basics: From Concepts to Casual Loops", 1997)

[360° feedback:] "A performance appraisal system that elicits input from an employee's boss, peers, and subordinates." (Dale Furtwengler, "Ten Minute Guide to Performance Appraisals", 2000)

"Information concerning the correctness of one's performance on a learning task or question. May also include explanations to guide learners to a correct response." (Ruth C Clark, "Building Expertise: Cognitive Methods for Training and Performance Improvement", 2008)

[explanatory feedback:] "Instructional responses to student answers to practice exercises that tell the learners whether they are correct or incorrect and also provide the rationale or a hint guiding the learners to a correct answer." ( Ruth C Clark, "Building Expertise: Cognitive Methods for Training and Performance Improvement", 2008)

[instructional feedback:] "Responses given by a trainer or program that may correct and/or offer explanations to learner responses to practice assignments." (Ruth C Clark, "Building Expertise: Cognitive Methods for Training and Performance Improvement", 2008)

[360° feedback] "A multi-source assessment that taps the collective wisdom of those who work with an individual, including supervisors, peers, direct reports, and internal and external customers." (Joan C Dessinger, "Fundamentals of Performance Improvement" 3rd Ed., 2012)

"Information provided by others designed to help people adjust their behavior, continue successful performance, or establish goals." (Joan C Dessinger, "Fundamentals of Performance Improvement" 3rd Ed., 2012)

"A process in which the effect or output of an action is 'returned' (fed back) to modify the next action." (Project Management Institute, "Navigating Complexity: A Practice Guide", 2014)

[peer feedback:] "A comment given by other learners on the learner’s response to an engagement activity. Peer feedback should be guided either by training or by a template. Peer feedback has been shown to promote learning of the individual giving the feedback." (Ruth C Clark & Richard E Mayer, "e-Learning and the Science of Instruction", 2016)

[normative feedback:] "An evaluation (often a grade) that compares the learner’s outcome with the outcomes of others. A common example is 'grading on the curve'. Because it directs attention to learners’ egos, normative feedback should be avoided." (Ruth C Clark & Richard E Mayer, "e-Learning and the Science of Instruction", 2016)

"Information concerning the correctness of one’s performance on a learning task or question. Effective feedback includes an explanation for correct and incorrect responses and should direct attention to the task or task process rather than the ego." (Ruth C Clark & Richard E Mayer, "e-Learning and the Science of Instruction", 2016)

"A reaction or response to a particular process or activity." (Project Management Institute, "Project Manager Competency Development Framework" 3rd Ed., 2017)

[360° feedback:] "The type of feedback in which project team members, project sponsors, and other stakeholders are surveyed anonymously in regard to the project manager's performance. This can be used to assess baseline competence in order to complete a competence gap analysis and create a development or training plan." (PMI, "Project Manager Competency Development Framework" 3rd Ed., 2017)

"Praising an employee when something good was accomplished (positive) and telling an employee when results are not up to expectations (constructive)." (Fred MacKenzie, "7 Paths to Managerial Leadership", 2016)

#️⃣Software Engineering: Programming (Part III: Football and Software Development)

 

Software Engineering Series

I wanted to write this post during the South Africa World Cup 2010 though because of the lack of time and because I was waiting for some statistics I could use, here I am, two weeks after the final whistle of the game for the first place. Football and Software Development, two domains that seems to have nothing in common, even if many software developers like to play football, and many football players are spending lot of time in front of their laptops. There is actually an important coordinate in what concerns the two – team work. Of course, that’s common to many other sports, though there are some characteristics important mainly to soccer -the small rate of deliverables (goals), the rate of failures (wrong passes), and I bet there are other characteristics common to most of the team sports, like the division and specialization of work, migration of players, “project”-oriented work, flow of money, etc.

Looking back at the games from this World Cup, we have to notice that, with a few exceptions, there wasn’t a big difference between the teams anymore, trend that could be seen during the last championships too, and there were no more individual players gaining one game after the other. Nowadays it primes the collective work, the cohesion of a team, the way the players respect the tactical indications given to them, the way they communicate and feel each other on the field. It didn’t matter anymore that you were playing against a Ronaldo, a Messi, Lampard, Drogba or Rooney, small teams like Australia, Chile, New Zeeland or South Korea, fighting as equal against the favorite teams of this tournament. 

What is more important to notice, is that teams whose players cost and make millions, didn’t function well (as expected) because the team haven’t played as a team, because the sense of individuality primed, because there was no adequate communication inside the team, while the trainer didn’t knew how to make himself respected, how to select his team, how to make/take the best out of his players, or how to change the tactics to counteract the one of the adversary. So the team with the best paid/skilled players, the team which puts more effort or controls the game, the team which has the most dynamic, effective (from the number of goals), beautiful or pragmatic play doesn’t necessarily win the game, same as the best trainer can make mistakes too, can make himself easier misunderstood or become overnight a persona non grata for its team or public.

 The same observations could be applied also to software development, and with the risk of being criticized I would say that the team with the best developers/professionals does not necessarily make a project successful, especially when the sense of individuality primes for the one of team, when the team members don’t play as a team, when there is no adequate communication, when the managers doesn’t make himself respected and know how to make/take the best out of his players, how to make a team successful no matter of the team’s number and skill-set. I tend to believe that in software development, same as in football, it must matter the joy for playing in a team, the joy for playing, being an example of professionalism, collaborating in achieving the purpose, helping each other to become better, no matter if one is named player, trainer, masseur, doctor or federation member.

I think that trainers have to learn more about project management, given the fact that building and leading a competitive team has a lot to do with projects and project management, being driven by similar goals, objectives, scope, etc. On the other side I feel that managers have to learn more from the behavior and knowledge of a trainer, to know how to be authoritarian and when to be a friend. And I expect that there are many other aspects the two types of professionals share. 

Also IT professionals can learn from football players, especially in what concerns the team spirit, what it takes to be/become a team, what it means to have your place in the field, do it right and for the best of the team. Of course, the self-sacrifice must not be brought to extreme, as some players do. In what concerns the football players, they could learn from developers the simplicity, abnegation for their work, the abnegation of becoming better, of learning something new, of finding and knowing their place in life, and overall of being humble.

As for the executives dealing with IT projects they must learn that a defender can’t become overnight a goal-getter or a goalkeeper, that a new comer in the team needs time to adapt himself, and must be helped to become integrant part, that the new comer needs to find its pace and place in the team. Executives must learn that it takes time, effort and a good strategy to built good successful teams, and even if everything revolves around money (although it shouldn’t), there should be kept a balance between investments, effort and rewards, some continuity, respect and support toward achieving successful and competitive teams.

Note:
If you liked/found interesting this post, then you might be interested also in Yohasna’s post What can we learn form SPAIN's World Cup Victory in the world of Software? and my answer to it, Satya’s Football and Software teams.. How different are they?, or B. Dwolatzky’s article on Football and Software Development are both team sports.

Previous Post <<||>>  Next Post

🏗️Software Engineering: Teams (Just the Quotes)

"A baseball manager recognizes a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. It is essential for great programming teams, too. Hustle provides the cushion, the reserve capacity, that enables a team to cope with routine mishaps, to anticipate and forfend minor calamities. The calculated response, the measured effort, are the wet blankets that dampen hustle. As we have seen, one must get excited about a one-day slip. Such are the elements of catastrophe." (Fred P Brooks, "The Mythical Man-Month: Essays", 1975)

"People who feel untrusted have little inclination to bond together into a cooperative team." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Whether you call it a 'team' or an 'ensemble' or a 'harmonious work group' is not what matters; what matters is helping all parties understand that the success of the individual is tied irrevocably to the success of the whole." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The obsession with methodologies in the workplace is another instance of the high-tech illusion. It stems from the belief that what really matters is the technology. [...] Whatever the technological advantage may be, it may come only at the price of a significant worsening of the team's sociology." (Tom DeMarco & Timothy Lister, "Peopleware", 1987)

"Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation." (Steve McConnell, "Rapid Development", 1996)

"Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively." (Steve McConnell, "Software Project Survival Guide", 1997)

"No project can succeed when the team members have no commitment to the plan, so the first rule of project planning is that the people who must do the work should help plan that part of the project. You will not only gain their commitment to the plan, but also most likely cover all of the important issues that you may individually have forgotten."(James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"Note that a project always begins as a concept, and a concept is usually a bit fuzzy. Our job as a team is to clarify the concept, to turn it into a shared understanding that the entire team will accept. It is failure to do this that causes many project failures." (James P Lewis, "Project Planning, Scheduling, and Control" 3rd Ed., 2001)

"Successful software development is a team effort - not just the development team, but the larger team consisting of customer, management and developers. [...] Every software project needs to deliver business value. To be successful, the team needs to build the right things, in the right order, and to be sure that what they build actually works." (Ron Jeffries, "Extreme Programming Installed", 2001)

"Failure usually results from a lack of a common approach to accomplish the work as a team. Inadequate leadership fails to create the environment in which teams can flourish. Furthermore, potential team members are seldom trained in how to share their efforts to accomplish team goals. The team may also assume they know more about teamwork than they actually do. So we need to be able to differentiate between superficial teamwork and the real thing." (Kevin Forsberg et al, "Visualizing Project Management: Models and frameworks for mastering complex systems" 3rd Ed., 2005)

"Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"You should choose a set of simple rules that govern the format of your code, and then you should consistently apply those rules. If you are working on a team, then the team should agree to a single set of formatting rules and all members should comply." (Robert C Martin, "Clean Code: A Handbook of Agile Software Craftsmanship", 2008)

"Teams should be able to act with the same unity of purpose and focus as a well-motivated individual." (Bill Gates, "Business @ the Speed of Thought: Succeeding in the Digital Economy", 2009)

"Coding standards are rules, sometimes relatively arbitrary, that define the coding styles and conventions that are considered acceptable within a team or organization. In many cases, agreeing on a set of standards, and applying them, is more important than the standards themselves." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"Few would deny the importance of writing quality code. High quality code contains less bugs, and is easier to understand and easier to maintain. However, the precise definitions of code quality can be more subjective, varying between organizations, teams, and even individuals within a team." (John F Smart, "Jenkins: The Definitive Guide", 2011)

"One of the worst symptoms of a dysfunctional team is when each programmer builds a wall around his code and refuses to let other programmers touch it." (Robert C Martin,"The Clean Coder: A code of conduct for professional programmers", 2011)

"Automation is an essential backbone of DevOps. Automation is the use of solutions to reduce the need for human work. Automation can ensure that the software is built the same way each time, that the team sees every change made to the software, and that the software is tested and reviewed in the same way every day so that no defects slip through or are introduced through human error." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"Conflicts between development and operations teams often originate from time pressures. Typically, a new software release must be deployed quickly. Another scenario that requires operations team to react quickly is when the system is down, and restoring it quickly becomes the highest priority. Th is situation often leads to a blame game where each side accuses the other of causing the problem." (Michael Hüttermann et al, "DevOps for Developers", 2013)

"Essential to improving collaboration is the alignment of incentives across teams as well as the application of shared processes and tools. The main attributes of aligned incentives include a shared definition of quality for the whole project or company and a commitment to it. Aligned with defined quality attributes, visibility and transparency can help to foster collaboration. Incentives must treat the development and operations groups as one team. That is, they should be rewarded for developing many changes that are stable and shipped."(Michael Hüttermann et al, "DevOps for Developers", 2013)

"The problem is that we cannot infer variations in individual productivity from data collected at the team level: we do not have an adequate theory of how a team’s productivity results from the aggregation of individual abilities, and in particular we cannot assume that a team’s output is a linear sum of individual 'productivities'." (Laurent Bossavit, "The Leprechauns of Software Engineering", 2015)

"There is common but flawed notion in enterprise IT circles that maintenance work requires less skill than full-scale development. As a result, project sponsors looking to reduce cost opt for a different team of lower-cost people for maintenance work. This is false economy. It hurts the larger business outcome and reduces IT agility." (Sriram Narayan, "Agile IT Organization Design: For Digital Transformation and Continuous Delivery", 2015)

"Any software project must have a technical leader, who is responsible for all technical decisions made by the team and have enough authority to make them. Responsibility and authority are two mandatory components that must be present in order to make it possible to call such a person an architect." (Yegor Bugayenko, "Code Ahead", 2018)

"Just by making the architect role explicit, a team can effectively resolve many technical conflicts." (Yegor Bugayenko, "Code Ahead", 2018)

"To make technical decisions, a result-oriented team needs a strong architect and a decision making process, not meetings." (Yegor Bugayenko, "Code Ahead", 2018)

"A key contribution of DevOps was to raise awareness of the problems lingering in how teams interacted (or not) across the delivery chain, causing delays, rework, failures, and a lack of understanding and empathy toward other teams. It also became clear that such issues were not only happening between application development and operations teams but in interactions with many other teams involved in software delivery, like QA, InfoSec, networking, and more." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"An obsession with 'feature delivery' ignores the human-related and team-related dynamics inherent in modern software, leading to a lack of engagement from staff, especially when the cognitive load is exceeded." (Matthew Skelton, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Organizations that rely too heavily on org charts and matrixes to split and control work often fail to create the necessary conditions to embrace innovation while still delivering at a fast pace. In order to succeed at that, organizations need stable teams and effective team patterns and interactions. They need to invest in empowered, skilled teams as the foundation for agility and adaptability. To stay alive in ever more competitive markets, organizations need teams and people who are able to sense when context changes and evolve accordingly." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Teams are always works in progress, but they are also your best shot at delivering value continuously and sustainably by aligning them with the business. Ideally, teams should be long lived and autonomous, with engaged team members. However, teams don’t live in isolation. They need to understand how and when to interact with each other. And these team interactions need to evolve over time to support the distinct phases of discovery and execution that products and technology go through during their lifetimes." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Teams take time to form and be effective. Typically, a team can take from two weeks to three months or more to become a cohesive unit. When (or if) a team reaches that special state, it can be many times more effective than individuals alone. If it takes three months for a team to become highly effective, we need to provide stability around and within the team to allow them to reach that level." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Programming is the immediate act of producing code. Software engineering is the set of policies, practices, and tools that are necessary to make that code useful for as long as it needs to be used and allowing collaboration across a team." (Titus Winters, "Software Engineering at Google: Lessons Learned from Programming Over Time", 2020)

"Engineering managers have a responsibility to optimize their teams. They improve engineering workflows and reduce dependencies and repetitive tasks. Self-sustaining teams minimize dependencies that hinder them in their efforts to achieve their objectives. Scalable teams minimize software delivery steps and eliminate bottlenecks. The mechanisms to achieve this may include the use of tools, conventions, documentation, processes, or abstract things such as values and principles. Any action that produces a tangible improvement in the speed, reliability, or robustness of your team’s work is worth your consideration." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"In a workplace setting, accountability is the willingness to take responsibility for one’s actions and their outcomes. Accountable team members take ownership of their work, admit their mistakes, and are willing to hold each other accountable as peers." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"Systems architecture is the portion of any project over which the engineering team has the most control. This design is usually less of a collaboration between different functions and more clearly in the domain of engineers. As such, engineering managers have a high responsibility to own this process and its decisions. To produce the best decisions possible, you must have the right decision-building blocks: complete information to work from and a structured methodology to guide you." (Morgan Evans, "Engineering Manager's Handbook", 2023)

"One of the great enemies of design is when systems or objects become more complex than a person - or even a team of people - can keep in their heads. This is why software is generally beneath contempt." (Bran Ferren)

⛩️Matthew Skelton - Collected Quotes

"A key contribution of DevOps was to raise awareness of the problems lingering in how teams interacted (or not) across the delivery chain, causing delays, rework, failures, and a lack of understanding and empathy toward other teams. It also became clear that such issues were not only happening between application development and operations teams but in interactions with many other teams involved in software delivery, like QA, InfoSec, networking, and more." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"A 'stream' is the continuous flow of work aligned to a business domain or organizational capability. Continuous flow requires clarity of purpose and responsibility so that multiple teams can coexist, each with their own flow of work. A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey, or a single user persona." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"An obsession with 'feature delivery' ignores the human-related and team-related dynamics inherent in modern software, leading to a lack of engagement from staff, especially when the cognitive load is exceeded." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"[…] decisions based on org-chart structure tend to optimize for only part of the organization, ignoring upstream and downstream effects. Local optimizations help the teams directly involved, but they don’t necessarily help improve the overall delivery of value to customers. Their impact might be negligent if there are larger bottlenecks in the stream of work." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"However, in a highly collaborative context filled with uncertainty over outcomes, relying on the org chart as a principal mechanism of splitting the work to be done leads to unrealistic expectations." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Organizations that rely too heavily on org charts and matrixes to split and control work often fail to create the necessary conditions to embrace innovation while still delivering at a fast pace. In order to succeed at that, organizations need stable teams and effective team patterns and interactions. They need to invest in empowered, skilled teams as the foundation for agility and adaptability. To stay alive in ever more competitive markets, organizations need teams and people who are able to sense when context changes and evolve accordingly." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Systems thinking focuses on optimizing for the whole, looking at the overall flow of work, identifying what the largest bottleneck is today, and eliminating it." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Teams are always works in progress, but they are also your best shot at delivering value continuously and sustainably by aligning them with the business. Ideally, teams should be long lived and autonomous, with engaged team members. However, teams don’t live in isolation. They need to understand how and when to interact with each other. And these team interactions need to evolve over time to support the distinct phases of discovery and execution that products and technology go through during their lifetimes." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Teams take time to form and be effective. Typically, a team can take from two weeks to three months or more to become a cohesive unit. When (or if) a team reaches that special state, it can be many times more effective than individuals alone. If it takes three months for a team to become highly effective, we need to provide stability around and within the team to allow them to reach that level." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"The org chart does have its uses in the context of building software systems, specifically around regulatory and legal compliance. However, in a highly collaborative context filled with uncertainty over outcomes, relying on the org chart as a principal mechanism of splitting the work to be done leads to unrealistic expectations. We need to rely instead on decoupled, long-lived teams that can collaborate effectively to meet the challenge of balancing speed and safety." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"The problem with taking the org chart at face value is that we end up trying to architect people as if they were software, neatly keeping their communication within the accepted lines." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

"Trying to determine the cognitive load of software using simple measures such as lines of code, number of modules, classes, or methods is misguided. […] When measuring cognitive load, what we really care about is the domain complexity - how complex is the problem that we’re trying to solve with software? A domain is a more largely applicable concept than software size." (Matthew Skelton & Manuel Pais, "Team Topologies: Organizing Business and Technology Teams for Fast Flow", 2019)

🖌️Tom DeMarco - Collected Quotes

"Anything you need to quantify can be measured in some way that is superior to not measuring it at all." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"As a general rule of them, when benefits are not quantified at all, assume there aren’t any." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Managers jeopardize product quality by setting unreachable deadlines. They don’​​​​​​t think about their action in such terms; they think rather that what they’​​​​​​re doing is throwing down an interesting challenge to their workers, something to help them strive for excellence." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Most of us managers are prone to one failing: A tendency to manage people as though they were modular components." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"People who feel untrusted have little inclination to bond together into a cooperative team." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"People under time pressure don’​​​​​​t work better - ​​​​​​they just work faster. In order to work faster, they may have to sacrifice the quality of the product and of their own work experience." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Programmers seem to be a bit more productive after they’​​​​​​ve done the estimate themselves, compared to cases in which the manager did it without even consulting them." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"[The common definition of estimate is] 'the most optimistic prediction that has a non-zero probability of coming true' [...] Accepting this definition leads irrevocably toward a method called what's-the-earliest-date-by-which-you-can't-prove-you-won't-be-finished estimating" (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The major problems of our work are not so much technological as sociological in nature. Most managers are willing to concede the idea that they’​​​​​​ve got more people worries than technical worries. But they seldom manage that way. They manage as though technology were their principal concern. They spend their time puzzling over the most convoluted and most interesting puzzles that their people will have to solve, almost as though they themselves were going to do the work rather than manage it. […] The main reason we tend to focus on the technical rather than the human side of the work is not because it’​​​​​​s more crucial, but because it’​​​​​​s easier to do." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The most obvious defensive management ploys are prescriptive Methodologies ('My people are too dumb to build systems without them') and technical interference by the manager. Both are doomed to fail in the long run." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The need for uniformity is a sign of insecurity on the part of management. Strong managers don’t care when team members cut their hair or whether they wear ties. Their pride is tied only to their staff’s accomplishments." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The obsession with methodologies in the workplace is another instance of the high-tech illusion. It stems from the belief that what really matters is the technology. [...] Whatever the technological advantage may be, it may come only at the price of a significant worsening of the team's sociology." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The purpose of a team is not goal attainment but goal alignment." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"The [software] builders’​​​​​​ view of quality, on the other hand, is very different. Since their self-esteem is strongly tied to the quality of the product, they tend to impose quality standards of their own. The minimum that will satisfy them is more or less the best quality they have achieved in the past. This is invariably a higher standard than what the market requires and is willing to pay for." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"When you automate a previously all-human system, it becomes entirely deterministic."(Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Whether you call it a 'team' or an 'ensemble' or a 'harmonious work group' is not what matters; what matters is helping all parties understand that the success of the individual is tied irrevocably to the success of the whole." (Tom DeMarco & Timothy Lister, "Peopleware: Productive Projects and Teams", 1987)

"Ability to change has to be an organic part of the organization. Change has to be going on all the time, everywhere. It needs to be everybody’s business."  (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"And the management team is not really a team. A team is a group of people who have joint responsibility for - and joint ownership of - one or more work products. People who own nothing in common may be called a team, but they aren’t. This is not to say that companies never form real management teams, only that they do so rarely. Most of what are called management teams are a mockery of the team concept." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Authoritarian management is obsessed with time. It is destructive of slack and inclined to goad people into outperforming their peers. And it makes learning impossible." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Change always implies abandonment. What you're abandoning is an old way of doing things. You're abandoning it because it's old, because time has made it no longer the best way. But it is also (again because it's old) a familiar way. And more important, it is an approach that people have mastered. So the change you are urging upon your people requires them to abandon their mastery of the familiar, and to become novices once again, to become rank beginners at something with self-definitional importance." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Each time you add automation, you choose some particularly mechanical component of the work (that’s what makes it a good candidate for automation). When the new automation is in place, there is less total work to be done by the human worker, but what work is left is harder. That is the paradox of automation: It makes the work harder, not easier. After all, it was the easy stuff that got absorbed into the machine, so what’s left is, almost by definition, fuzzier, less mechanical, and more complex. Whatever standard is now introduced to govern the work will dictate (often in elaborate detail) how the few remaining mechanical aspects are to be performed."  (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Growth is the rising tide that floats all boats. The period of growth is one in which people are naturally less change-resistant. It is therefore the optimal time to introduce any change. Specifically, changes that are not growth-related should be timed to occur during growth periods. This is not because they are strictly necessary then, but because they are more likely to be possible then. You need that advantage going up against Goliath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"How people feel can be more a factor in the success of a change than what they think. Anxiety of any kind can only complicate the task of change introduction. That’s why the period of sudden decline of corporate fortunes is exactly the worst moment to introduce a change. People are uneasy about their jobs, worried about lasting corporate health, perhaps shocked by the vitality of the competition. In retrospect, a far better time to introduce the change would have been back in the period of healthy growth. Growth always carries with it a certain necessity for change. You may have to hire more people, expand to larger quarters, diversify or centralize, all to accommodate your own burgeoning success. But growth feels good; it feels like winning. It even feels good enough to reduce the amount of change resistance." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"In order to enable change, companies have to learn that keeping managers busy is a blunder. If you have busy managers working under you, they are an indictment of your vision and your capacity to transform that vision into reality. Cut them some slack." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"In the most highly stressed projects, people at all levels talk about the schedule being 'aggressive', or even 'highly aggressive'. In my experience, projects in which the schedule is commonly termed aggressive or highly aggressive invariably turn out to be fiascoes. 'Aggressive schedule', I’ve come to suspect, is a kind of code phrase - understood implicitly by all involved - for a schedule that is absurd, that has no chance at all of being met." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Lack of power is a great excuse for failure, but sufficient power is never a necessary condition of leadership. There is never sufficient power. In fact, it is success in the absence of sufficient power that defines leadership." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Leadership is the ability to enroll other people in your agenda. Meaningful acts of leadership usually cause people to accept some short-term pain (extra cost or effort, delayed gratification) in order to increase the long-term benefit. We need leadership for this, because we all tend to be short-term thinkers." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Management is hard, and not because there is so much work to do (an overworked manager is almost certainly doing work he/she shouldn’t be doing). Management is hard because the skills are inherently difficult to master. Your mastery of them will affect your organization more than anything going on under you." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Meaningful acts of leadership usually cause people to accept some short-term pain (extra cost or effort, delayed gratification) in order to increase the long-term benefit. We need leadership for this, because we all tend to be short-term thinkers." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Ownership of the standard should be in the hands of those who do the work." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Process standardization from on high is disempowerment. It is a direct result of fearful management, allergic to failure. It tries to avoid all chance of failure by having key decisions made by a guru class (those who set the standards) and carried out mechanically by the regular folk. As defense against failure, standard process is a kind of armor. The more worried you are about failure, the heavier the armor you put on. But armor always has a side effect of reduced mobility. The overarmored organization has lost the ability to move and move quickly. When this happens, standard process is the cause of lost mobility. It is, however, not the root cause. The root cause is fear." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Quality takes time and reduces quantity, so it makes you, in a sense, less efficient. The efficiency-optimized organization recognizes quality as its enemy. That's why many corporate Quality Programs are really Quality Reduction Programs in disguise." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Risk management is the explicit quantitative declaration of uncertainty. But in some corporate cultures, people aren’t allowed to be uncertain. They’re allowed to be wrong, but they can’t be uncertain. They are obliged to look their bosses and clients in the face and lie rather than show uncertainty about outcomes. Uncertainty is for wimps." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Risk mitigation is the set of actions you will take to reduce the impact of a risk should it materialize. There are two not-immediately-obvious aspects to risk mitigation: The plan has to precede materialization. Some of the mitigation activities must also precede materialization." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Significant organizational learning can’t happen in isolation. It always involves the joint participation of a set of middle managers. This requires that they actually talk to each other and listen to each other, rather than just taking turns talking to and listening to a common boss." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Slackless organizations tend to be authoritarian. When efficiency is the principal goal, decision making can't be distributed. It has to be in the hands of one person (or a few), with everyone else taking direction without question and acting quickly to carry out orders. This is a fine formula for getting a lot done, but a dismal way to encourage reinvention and learning." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"The premise here is that the hierarchy lines on the chart are also the only communication conduit. Information can flow only along the lines. [...] The hierarchy lines are paths of authority. When communication happens only over the hierarchy lines, that's a priori evidence that the managers are trying to hold on to all control. This is not only inefficient but an insult to the people underneath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"The right way to think about domain knowledge is as a corporate capital asset, as dollars of investment in the head of each knowledge worker, put there by organizational investment in that employee. When that person leaves, the asset is gone. If you did a rigorous accounting of this human capital, you would be obliged to declare an extraordinary loss each time one of your people quit." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"The rule is (as with children) that trust be given slightly in advance of demonstrated trustworthiness. But not too much in advance. You have to have an unerring sense of how much the person is ready for. Setting people up for failure doesn’t make them loyal to you; you have to set them up for success. Each time you give trust in advance of demonstrated performance, you flirt with danger. If you’re risk-averse, you won’t do it. And that’s a shame, because the most effective way to gain the trust and loyalty of those beneath you is to give the same in equal measure." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"There is no such thing as 'healthy' competition within a knowledge organization; all internal competition is destructive. The nature of our work is that it cannot be done by any single person in isolation. Knowledge work is by definition collaborative. The necessary collaboration is not limited to the insides of lowest-level teams; there has to be collaboration as well between teams and between and among the organizations the teams belong to." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"When a schedule is not met, those inclined to pass out blame are quick to point at the lowest-level workers; they reason that performance is the domain entirely of those who perform the work. They ask plaintively, 'Why can’t these guys ever meet their schedules?' The answer that the schedule might have been wrong in the first place only befuddles them. It’s as though they believe there is no such thing as a bad schedule, only bad performances that resulted in missing the scheduled date. There is such a thing as a bad schedule. A bad schedule is one that sets a date that is subsequently missed. That’s it. That’s the beginning and the end of how a schedule should be judged. If the date is missed, the schedule was wrong. It doesn’t matter why the date was missed. The purpose of the schedule was planning, not goal-setting. Work that is not performed according to a plan invalidates the plan. The missed schedule indicts the planners, not the workers." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"When communication happens only over the hierarchy lines, that’s a priori evidence that the managers are trying to hold on to all control. This is not only inefficient but an insult to the people underneath." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"When managers are overworked, they’re doing something other than management; the more they allow themselves to be overworked, the less real management gets done." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"Whether this person is a designer, product manager, programmer, writer, consultant, or whatever, he/she comes with (1) a set of skills and (2) some explicit knowledge of the area in which skills are to be deployed. The skills alone aren’t enough. Domain knowledge is also required. The more important that domain knowledge is, the less fungible the people are. That means you can’t divide them up into pieces, but it also means that you can’t easily replace them with other people when they leave." (Tom DeMarco, "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency", 2001)

"If you've been in the software business for any time at all, you know that there are certain common problems that plague one project after another. Missed schedules and creeping requirements are not things that just happen to you once and then go away, never to appear again. Rather, they are part of the territory. We all know that. What's odd is that we don't plan our projects as if we knew it. Instead, we plan as if our past problems are locked in the past and will never rear their ugly heads again. Of course, you know that isn't a reasonable expectation." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"Risks and benefits always go hand in hand. The reason that a project is full of risk is that it leads you into uncharted waters. It stretches your capability, which means that if you pull it off successfully, it's going to drive your competition batty. The ultimate coup is to stretch your own capability to a point beyond the competition's ability to respond. This is what gives you competitive advantage and helps you build a distinct brand in the market." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"The business of believing only what you have a right to believe is called risk management." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"The pathology of setting a deadline to the earliest articulable date essentially guarantees that the schedule will be missed." (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

"There is probably no job on earth for which an ability to believe six impossible things before breakfast is more of a requirement than software project management."  (Tom DeMarco & Timothy Lister, "Waltzing with Bears: Managing Risk on Software Projects", 2003)

🖌️James Surowiecki - Collected Quotes

"Diversity and independence are important because the best collective decisions are the product of disagreement and contest, not consensus or compromise." (James Surowiecki, "The Wisdom of Crowds", 2005)

"Groups are only smart when there is a balance between the information that everyone in the group shares and the information that each of the members of the group holds privately. It's the combination of all those pieces of independent information, some of them right, some of the wrong, that keeps the group wise." (James Surowiecki, "The Wisdom of Crowds", 2005)

"Errors in individual judgment won’t wreck the group’s collective judgment as long as those errors aren’t systematically pointing in the same direction. One of the quickest ways to make people’s judgments systematically biased is to make them dependent on each other for information." (James Surowiecki, "The Wisdom of Crowds", 2005)

"The fact that cognitive diversity matters does not mean that if you assemble a group of diverse but thoroughly uninformed people, their collective wisdom will be smarter than an expert's. But if you can assemble a diverse group of people who possess varying degrees of knowledge and insight, you're better off entrusting it with major decisions rather than leaving them in the hands of one or two people, no matter how smart those people are." (James Surowiecki, "The Wisdom of Crowds", 2005)

"The smartest groups, then, are made up of people with diverse perspectives who are able to stay independent of each other." (James Surowiecki, "The Wisdom of Crowds", 2005)

"[...] under the right circumstances, groups are remarkably intelligent, and are often smarter than the smartest people in them. Groups do not need to be dominated by exceptionally intelligent people in order to be smart. Even if most of the people within a group are not especially well-informed or rational, it can still reach a collectively wise decision." (James Surowiecki, "The Wisdom of Crowds", 2005)