»
S
I
D
E
B
A
R
«
Don’t waste your time on who’s to blame
Jun 20th, 2014 by Joca

Whenever errors occur, some people have a natural tendency as their first reaction to look for someone to blame. Specially in group activities. As if having someone to blame would somehow make the error less harmful. This is a big waste of time and energy. Let me explain why.

blame

Waste of time

An error occurred. Errors happen. This is a fact of life. No matter what you are doing, designing software, deploying code in production, operating on a patient, cooking dinner, building a house, playing guitar, playing soccer, etc. chances are that erros will occur.

When you spend time trying to find who was responsible for the error, you’ll delay your most important tasks regarding the error:

  • understanding what happened
  • figuring out how to fix it
  • find ways to prevent it to happen again

Waste of energy

When you spend time trying to find who was responsible for the error, people may naturally try to hide because they are afraid of the consequences. Will I be fired? Will I be excluded from the group? Will I be punished? Will people mock me?

When people try to hide who was responsible, you’ll again delay your most important tasks regarding the error listed above because it will be more difficult to understand what happened. People will not tell the whole truth and nothing but the truth about the error and the circumstances surrounding the error.

Deal with the responsible in private

If in the process of understanding what happened you find out that someone was responsible for the error, deal with him in private. Most probably he caused the error without intention to do any harm. So on one side you need to help him improve so he doesn’t do this kind of errors in the future. On the other side you have the responsibility to create an environment where it’s safe to tell about the errors so these errors are detected more quickly.

Lessons learned

  • When an error occur, don’t waste your time on who’s to blame.
  • Focus your energy on understanding what happened.
  • Figure out how to fix it.
  • Find ways to prevent the error from happening again.
  • If you find out someone was responsible, deal with him in private, and help him improve.
3 people like this post.

The IT problem
Mar 7th, 2014 by Joca

I have talked to some people lately about IT departments and how they seem disconnected from the companies they belong to, often being very reactive to business demands. It is common to hear complaints from the business people about IT saying they almost never deliver what was asked and that it is hard to understand what they say. On the other hand, it is also common to hear IT folks saying that the business area does not know what they want and that IT cannot answer “zillion” high priority demands of the business. This lack of understanding between IT and the business area of ​​the company is so common that it even became a subject of cartoons of all kinds:

IT-project

dilbert

But what is wrong? What is the IT problem?

Software development

For those who live in the part of IT that has to do with software development, this problem has been addressed for some time now. The Agile Manifesto, from 2001, makes this clear:

  • We have come to value customer collaboration over contract negotiation.
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Business people and developers must work together daily throughout the project.

As the software developers need to deploy their software somewhere, they decided to involve the people who takes care of the production environment in this new way of thinking that bring together IT and business. Thus was born the DevOps movement in 2009:

DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

Source: Wikipedia

In these software development teams it is common to see someone with the role of Product Owner or Product Manager. This is a role I’ve already described earlier:

Product Manager is responsible for all aspects of a software product, from strategic objectives to the details of the user experience. She is responsible for making the connection between the business strategy and the problems and needs of customers through the software that should help the company achieve its strategic objectives while solving the problems and needs of the customers.

The IT problem

Now imagine the IT department of Gap, American Airline, Disney, MIT or any other non-tech company. These IT departments will have among its scope the following functions:

  • Hardware inventories.
  • Software inventory and installation.
  • Server availability monitoring and metrics.
  • Security management.
  • Anti-virus and anti-malware management.
  • Anti-manipulation management.
  • User’s activities monitoring.
  • Capacity monitoring.
  • Storage management.
  • Network capacity and utilization monitoring.

As you can see, these IT departments already have enough stuff to worry about and will hardly develop software. If they choose to develop software, they will most likely use third parties to do this development. Even if they decide to develop internally, software development is still a small piece of IT. The concern of these IT areas is with how to integrate off-the-shelf software and make them work to meet the business needs.

The problem is that unlike software development, which already discovered the importance of having a product manager to help deliver results more aligned with the business, all other functions of an IT department does not have this bridge between IT and the business.

One possible solution to the IT problem

I would like to propose a solution to the IT problem: have more people with the role of “product manager”. I believe that name does not fit very well when the IT delivery is not software. That person will need to create a bridge between IT and business. Perhaps a more appropriate name is “business manager”.

This person would have the following responsibilities:

  • Gather IT needs in all areas of the company and identify and propose solutions to any conflicts between these needs.
  • When these requirements have impact on the end customer of the company, understand this impact on these customers.
  • Negotiate requirement implementation priorities with all business areas.
  • Work with IT teams to ensure that deliveries are made in accordance with the requirements gathered with the other departments of the company.
  • Act with the demanding areas and IT teams on any relationship with suppliers / partners. (e.g. banks, consultants, etc.)
  • Inform all areas of the company on new IT implementations as well as upcoming implementations. Prepare training as needed.
  • Work with marketing to inform customers when the new implementations are customer facing.
  • Define, track and analyze usage metrics from IT, to use them as further relevant information for decision making.

And to be able to carry out these responsibilities, this person needs to have:

  • Experience working with IT teams to deliver quality projects within expected deadlines.
  • Good understanding of IT and technical topics to be able to negotiate delivery options. Having been in the IT field is not required, but may help in the function.
  • General knowledge about the company’s products and services, as well as an understanding of the different departments of the company.
  • Good oral and written communication skills.
  • Negotiation skills between different stakeholders with different priorities.
  • Ability to documente requirements and use cases.
  • Leadership.

As you can see from the above description, this person have a senior profile. It will be a pair of the IT manager.

A question that may arise while reading this proposal to add a “business manager” to the IT team is why IT managers can not assume this role? Actually, they can, but they shouldn’t. IT managers already have many concerns. The IT manager has two main focuses, technology and people. She needs to be up-to-date on the technologies in her area to learn how to better meet the needs that arise. And she needs to manage the team, finding and coordinating good IT professionals is no an easy task. Putting on the IT manager the additional burden of business requirement management can lower the overall quality in current tasks.

In software development we’ve realized that it’s better to have a separate person taking care of business needs. Why not apply the same role separation for other IT areas?

4 people like this post.

More thoughts on participative management
Dec 5th, 2013 by Joca

By the end of October I went to Business of Software conference, an interesting conference about, well, the business of software. Many interesting speakers and interesting people in the audience to chat.

One of the presentations was given by Scott Berkun, who was team lead at WordPress.com from 2010 to 2012. WordPress.com has over 10 billion page views per month, fewer than 200 employees and everyone gets to work from home making it a very interesting environment to think about the future of the workplace. He told us about the advantages and challenges of a distributed work environment, what we can consider as an innovation in management. His presentation was very interesting but when he got to the Q&A session, he got the inevitable question about Yahoo! and their move back from the remote working policy. His answer was very straight forward: since Yahoo! is in a crisis, they cannot afford the management innovation, it is natural that they revoked this policy and returned to traditional management practices, in this case, co-location of workers.

So this got me thinking, whenever a company faces a crisis, it should stop innovation management and should go back to traditional management?

Participative management in a crisis environment

Today I had again the opportunity to join a conversation with Clóvis Bojikian and Heiko Fischer. This was the third or forth encounter we had and, as always, the conversation was very interesting, full of ideas, examples and how-tos related to participative management.

Heiko    Clovis

At a certain point Clóvis told about a crisis at Semco, during the Collor president years, where the market was abruptly opened to foreign companies. That impacted Semco and forced them to do a downsize, which is always painful. Clóvis discussed with the workers how they wanted to do it and the workers told that they would provide a list of people that should not be laid off either because of age or personal issues and they said to the managers that, preserving the people in that list, the manager could select who should be laid off based on technical criteria. Two things we can pick from this episode:

  • Even in a crisis there’s no need to abandon management innovations such as participative management. It’s a good test for the management innovation, to see if it’s capable to cope with the crisis at hand. In this case, participative management was able to cope with the need for lay offs due to a crisis in the market.
     
  • There are a lot of numbers between 0 and 1, i.e., it’s not a matter of participative management or non-participative management. There are options in between, there are decisions that workers are willing to cope with and others that they don’t want to cope with and each issue will require a different mix.

It takes a tyrant to sustain participative management

Back in 2008 I read a very interesting article entitled “Sometimes It Takes a Tyrant to Support Collaboration“. We were in the initial steps agile implementation at Locaweb and this article showed that even though one of the outcomes of agile implementation would be self managed teams, this was not a natural outcome, and it requires a constant push from leaders to move into that direction.

Now I have the impression that the same happens with participative management. Even though this is an outcome appreciated by many workers, this is not a natural outcome. It requires that someone forces and sustains the move into this direction. Clóvis and Ricardo Semler did that at Semco. Heiko did that at the largest video game maker in Europe. I did that with my teams at Locaweb. We need to force and reinforce this behavior until it is imprinted in the company’s or team’s culture.

Heiko told about a decision they made in a company facing an economic crisis where the options where to either lay off people or cut 20% of the salaries of everybody so there won’t be any lay offs. Obviously the team preferred the second option. I said to Heiko that in Brazil that’s not an option since we can’t reduce salaries. He told that this is not possible in Europe either, but they figure out a way to do it. Employees would deposite 20% of their salaries in a company fund. At this moment Clóvis told that they also did that at Semco, in agreement with the Union.

Another exemple given by Clóvis was about employee time tracking. In Brazil it is required to have time tracking of all employees but at Semco they wanted to free up the workers from this hassle and show them they trust them. Even though they were subject to a fine if they didn’t do time tracking, they decided to pay the fine but keep off the time tracking to show workers their trust. So they found a way to support participative management even if it has costs.

This is an interesting paradox: in order to implement participative management you need to force it’s implementation, it doesn’t just happen. You need to force and sustain the movement into this direction, even more in crisis.

3 people like this post.

HR, participative management, democracy in the workplace and leadership
May 6th, 2013 by Joca

Readers of this blog already know Clóvis Bojikian, former Semco’s HR director. Back in 2009, when I met Clóvis, I wrote a long post about Clóvis experience in participative management.

One month ago I received a Linkedin invitation to connect with Heiko Fischer:

Salut Joaquim,
I follow your blog and love it! My team made HR redundant at Europe’s largest videogames company. We called it the Way of Resourceful Humans, basically democratic entrepreneurship. I was wondering if you could get me in touch with Clóvis Bojikian. I would love to invite him! Thank you!

Doing some research I was able to find this TED presentation:

It’s easy to see that Heiko’s ideas are in synch with Clóvis experience. I instantly put them in contact and arranged for them to meet over Skype. This meeting occurred last week and it was a pleasure and an honour to be part of the conversation between those two top HR professionals so ahead of their own time. The conversation could certainly generate many posts, but I’d like to write specifically about the beginning and the end of the conversation.

In the beginning of the conversation, Heiko told a bit about his history. He told that his father worked in HR at HP and there democracy in the workplace was a value brought by the founders, so Heiko thought this was common place. Following the steps of his father, Heiko decided to work in HR as well and to his surprise, companies were far from democratic and HP was much more an exception than the rule.

At this moment, Clóvis congratulated Heiko for following his father’s steps. Normally children tend to go the opposite direction of their parents, just for the sake of opposing their parents’ opinion. Heiko replied that actually he went in the opposite direction of his father. While his father believed that in order to maintain democracy in a company it is needed a strong HR department, Heiko’s view is that the perfect democratic company is one where HR is no longer needed.

After that, the conversation followed with Heiko and Clóvis exchanging experiences, telling each other how they implemented participative management and democracy at workplace and their motivation to do so.

At the end, after Heiko hung up, I was walking with Clóvis on his way out when I mentioned how interesting Heiko’s view on HR that the perfect democratic company is one where HR is no longer needed. Then Clóvis completed “and managers are no longer needed as well”.

5 people like this post.

Using checklists to deal with the unexpected
Jan 2nd, 2012 by Joca

I mentioned earlier about “The Checklist Manifesto” book. The post was originally written in Portuguese but you can find a Google translation here. In this post I mentioned about the use of checklist in surgeries and other medical procedures and how we could use checklists in the IT environment.

I was reviewing my Kindle highlights for this book and found this highlight:

Surgery has, essentially, four big killers wherever it is done in the world: infection, bleeding, unsafe anesthesia, and what can only be called the unexpected. For the first three, science and experience have given us some straightforward and valuable preventive measures we think we consistently follow but don’t. These misses are simple failures — perfect for a classic checklist. And as a result, all the researchers’ checklists included precisely specified steps to catch them.

But the fourth killer — the unexpected — is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together — to be ready as a team to identify and address each patient’s unique, potentially critical dangers.

Dr. Gawande found out that in order to address the unexpected, checklists should not only include task checks but also communication checks. Dr. Gawande got to that conclusion visiting a 700,000-square-foot office and apartment complex construction site with between two to five hundred workers on-site on any give day managed by a man called Finn O’Sullivan. The volume of knowledge and degree of complexity O’Sullivan manages is impressive and it was as monstrous as anything Dr. Gawande had encountered in medicine. Here’s the explanation:

It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another — on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction — who had to share (or “submit”) particular kinds of information before the next steps could proceed.

The submittal schedule specified, for instance, that by the end of the month the contractors, installers, and elevator engineers had to review the condition of the elevator cars traveling up to the tenth floor. The elevator cars were factory constructed and tested. They were installed by experts. But it was not assumed that they would work perfectly. Quite the opposite. The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted.

So next time you design a checklist, remember to include not only task checks but also communication checks.

3 people like this post.

What type of entrepreneur are you?
Oct 5th, 2011 by Joca

Some time ago Rafael Rosa (@rafaelrosafu) presented me the concept of lifestyle startup in opposition to the growth startup everybody knows.

Growth startups vs lifestyle startups

Growth startups – or companies- are startups that have one main objective, accelerated growth so it can make founders, investors and shareholders substantially rich when the startup is acquired or make an IPO. When you are focused on accelerated revenue growth, all your actions are driven by this goal, which has top priority on top of all other matters, including products, customers, employees, suppliers, quality, etc. Normal product question you hear in this type of startup is “how do we make this product sell more faster?” or “can we create another product or add-on feature to charge some extra money from existing customers?”. In this type of startup you tend to have people passionate about money.

Lifestyle startups – or companies – are startups where revenue has the objective to sustain the company and it’s founders and employees lifestyle. As soon as this issue (company sustainability as well as founders and employees lifestyle sustainability) is solved, the company can have full focus on product, customer, employees, suppliers, quality, etc. Normal product question in this type of company is “how do we make a great product that solves real customers problems?”. In this type of startup you tend to have people passionate about the product.

Sometimes it can be difficult to identify what type the startup – or company – is, but normally a conversation with the founders or some key employees around the topic of company purpose and people’s passion have good potential to help you identify the type of startup you’re dealing with.

Thinking as a customer and another comparison with the medical world

Moving the point of view from the startup founder to the customer, i.e., use your customer hat and think as a customer. What type of startup do you think would you, as the customer, prefer to solve your problems?

People who read my posts knows I like to make comparisons between business world and medical world:

So here goes another analogy using the medical world. Move again your point of view and suppose you are a patient who received the news that you have a certain issue that requires surgery. What doctor would you choose to do this surgery, one who’s primary purpose is to get rich with medical practice or one who is really passionate about medicine and about making other people’s life better? Again, sometimes is difficult to identify the type of doctor we are talking to, but normally the way she describes your case and how it could be solved will give you hints on what type of doctor she is.

Conclusion

Ok. So back to my original question: what type of entrepreneur are you?

2 people like this post.

Pick your battles
Sep 1st, 2011 by Joca

There’s a Seth Godin’s post that I always use as a reference:

Gravity is a constraint. If you’re a designing an airplane, it would be a lot easier without gravity as a concern, but hey, it’s not going away.

A problem is solvable. A constraint must be lived with.

The art is in telling them apart.

Source: Problems and constraints

This post always reminds me of that old saying that tell us pick our battles carefully. Specially if the battle is a constraint.

3 people like this post.

Management 3.0
Aug 28th, 2011 by Joca

I mentioned earlier that one of the sources I’ve been reading and enjoying is Jurgen Appelo’s posts about agile management. I’ve been reading his posts for a while, since the time he was the CTO of a dutch company. I really like the way he connects agile methodologies and complex adaptive systems theory.

I’ve mentioned his work in 4 posts:

Now he is 100% focused on his agile management coach career. He recently launched a book entitled “Management 3.0: Leading Agile Developers, Developing Agile Leaders“.

He also provides Agile Management courses.

Last week he was in São Paulo providing his management course at AdaptWorks and I had the opportunity to attend his course.

I’ll make a brief summary of the course below, as a way for me to review what we discussed during this two days. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.

Intro

After a quick introduction about the ideal size of a group and quick introductions of the attendees, Jurgen explained quickly about agile software development and then introduced Martie, the Management 3.0 representation with the 6 aspects of management that we should take care if we want to be good managers.

Martie

Martie

Then Jurgen explained briefly about the theory of complex systems and the types of fallacies we may fall into if we don’t use complex systems thinking when managing teams.

The seven fallacies

The seven fallacies

To end the introductory section, we did a group exercise where we analyzed some situations to identify what was the fallacy in play.

Energize people

When discussing about people, Jurgen talked about intrinsic and extrinsic motivation and presented us with the 10 intrinsic desires:

  • Acceptance The need for approval
  • Curiosity The need to think
  • Power The need for influence of will
  • Honor Being loyal to a group
  • Social Contact / Relatedness The need for friends
  • Idealism / Purpose The need for purpose
  • StatusThe need for social standing
  • Independence / Autonomy Being an individual
  • Order Or stable environments
  • Competence / Mastery The need to feel capable

Intrinsic desires

Intrinsic desires

Exercise time: we analyzed individually how we are in our current jobs in terms of each of these 10 intrinsic desires.

Then Jurgen presented some tools to helps us know what is important for the people in our team:

B = f (P, E)

B = f (P, E)

Group exercise: we had to use the practices below to get to know 10 important facts about Ellen, a member of a fictional team managed by us.

Empower teams

Here Jurgen presented the 7 delegation levels I already mentioned in a previous post.

Delegation levels

Delegation levels

Group exercise: delegation poker where we were presented with different situations where we needed to figure out the appropriate delegation level.

Align constraints

A leader must:

  • define the constraints (playing field, players), but let the system create its own rules.
  • protect people against bad team formation
  • protect good teams against non-team players
  • protect shared resources (energy, budget, environment, office space, food, sysadmins)

The 4 I’s to cope with the Tragedy of the Commons:

  • Institutions: create trust to accept common rules
  • Information: increase understanding of situation
  • Identity: increase social belonging across teams
  • Incentives: address behaviors with small rewards

3 kinds of purpose (or goal) for a team:

  • Intrinsic purpose: an easily spottable trend in a team, e.g., produce software.
  • Extrinsic purpose: assigned by caretaker, e.g., make money.
  • Emergent purpose: chosen by the team, e.g., be a winning team.

Qualities of a good goal

Qualities of a good goal

Exercise time: we had to define a purpose for the course.

Develop competence

First Jurgen described how we can improve.

Competency development

Competency development

Then he described how we can measure our improvement.

KPI matrix

KPI matrix

Exercise time: we had to define KPIs according to the matrix above to our organization.

Grow structure

We can have two types of team organization, functional or cross-functional, it depends on how often team members need to communicate. Product managers, user experience designers and software developers need to communicate all the time about the project or product they are working on, so they need to sit together in a cross functional team. HR people on the other hand need to talk constantly to other HR people so they need to sit in a functional HR team.

Jurgen also advised we should hire generalizing specialists, promote informal leadership and widen job titles.

Exercise time: Meddlers.

Meddlers

Meddlers

Improve everything

How can I…

  • Make the rest of the organization more Agile?
  • Motivate my employees to develop themselves?
  • Convince customers they should accept Scrum?
  • Etc…

In order to change things we need to consider:

The system

  • Plan: What Is Your Goal?
  • Plan: Where Is It Going Well?
  • Do: What Are the Crucial Steps?
  • Do: When and Where Do You Start?
  • Check: How Do You Measure Results?
  • Check: How Do You Get Feedback?
  • Act: How Do You Accellerate Results?

The individuals

  • Awareness: How Will You Communicate?
  • Awareness: How Will You Set an Example?
  • Desire: How Do You Make It Urgent?
  • Desire: How Do You Make It Desirable?
  • Knowledge: What Will You Tell Them?
  • Knowledge: Who Will Be Teaching?
  • Ability: What Makes It Easy?
  • Ability: How Can They Practice?
  • Reinforcement: What Are the Short-Term Wins?
  • Reinforcement: What Makes It Sustainable?

The interactions

  • Initiators: Are You Committed?
  • Initiators: Who Is Assisting You?
  • Innovators: Who Will Be the Innovators?
  • Early Adopters: Who Are the Early Adopters?
  • Early Adopters: How Will the Leaders Help?
  • Early Majority: How Do You Reach the Early Majority?
  • Early Majority: How Will You Cross the Chasm?
  • Late Majority: How Will You Deal with Skeptics?
  • Laggards: How Do You Prevent a Relapse?
  • Laggards: How Do You Deal with Resistance?

The environment

  • Information: How Do You Make Things Visible?
  • Information: How Do You Ease Communication?
  • Identity: What Is the Group Identity?
  • Identity: How Can You Apply Peer Pressure?
  • Incentives: Can You Incentivize Good Behavior?
  • Infrastructure: Which Barriers Will You Remove?
  • Infrastructure: Which Guides Will You Place?
  • Institutions: Who Can Make the Rules?

Culture changes only after you have successfully altered people’s actions, after the new behavior produces some group benefit for a period of time.

John P. Kotter, Leading Change

Exercise time: each member of the group tell one story with she needs ideas on how to change, then the group select from the list above and discuss.

Conclusion

This is just a brief summary of the 2-day course, as a way for me to review what we discussed during. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.

11 people like this post.

Try AND instead of OR
Jul 20th, 2011 by Joca

I recently read the post “And” Leadership written by Jim Highsmith that caught my attention on using AND instead of OR:

One of the traits I think is very important [for an agile leader or manager] is that of “And” rather than “Or” leadership. The most pressing issues to face leaders are usually paradoxical; they appear to have contradictory solutions. Take for example the paradox of needing predictable delivery with that of needing to be flexible and adapt over the life of a project.

It’s easy to be an “or” leader. Pick a side and state your case loudly, over and over until the opposition gives up. It’s much more difficult to be an “and” leader, balancing between seemingly opposite strategies. However, in our ever-changing and turbulent world, slavishly following the “one right answer” is a recipe for disaster.

It’s interesting that in many situations in agile development we face situations where we initially think it’s an OR situation but when we analyze it, we realize it’s actually an AND situation where we need to balance apparently opposing concepts:

  • freedom and responsibility
  • cross-functionality and specialization
  • continuous learning and iteration pressure

It’s interesting that this applies not only to agile development but to many aspects of our life. Should I be more concerned about my family or my job? Should I give more attention to my kids or my companion? Experiment changing or by and. 🙂

Lessons learned

Next time you face a situation with opposing concepts, instead of choosing the easy path of taking sides and being an OR person, try to figure out a way to be an AND person. It will be much more difficult to ben an AND person. Sometimes it won’t even be possible to use AND in certain situations, but just trying to figure out if it is possible will be a good exercise with interesting outcomes.

1 person likes this post.

Why there are so few women in programming and why this matters
Jun 19th, 2011 by Joca

Sometime ago I was talking to some friends from ThoughtWorks when one of them asked me why there are so few women in the IT industry? Specifically, why there are so few women in programming?

Since I’m an open water swimming aficionado my first reaction – quite naïve reaction by the way – was to attribute to the physical gender differences such as we see in sports. Women don’t compete with men in sports because there are physical differences. A women world record in any swimming event is different from men world record. But my friends replied that there aren’t any known physical differences that can justify why there are so few women in the IT industry. And they pointed out that the right direction for an answer was in the social and cultural realms. So I kept thinking about this topic, did some research and I want to share my findings.

Background

I still don’t know why but my parents decided to put me in a male only school from 6 to 17 years old. My school decided to accept girls when I was 15. In my last year of school I had to choose between exact, bio or human sciences as part of the preparation for entering university. I chose exact science and my classroom of 35 people had only 2 girls. I started to realize that exact science and girls were not best friends. By then I decided to go to engineering school. I heard that there are not so many women in engineering schools and I went to visit some of them. I decided to go to ITA, a male only engineering school. It was a male only school because during their first year at ITA, the undergraduate students are required to attend a military preparation course once a week. This is due to ITA’s strong connection with the Air Force. Some years ago ITA decided to accept women. After graduating at ITA, I worked at 4 internet service provider companies and in all of them women was a minority, specially in the technical teams.

So the lack of women in exact sciences and technology has been part of my entire life, even though I haven’t paid much attention to this until recently.

Why gender diversity matters

First, diversity in general matters since diversity brings new ideas, new opinions and new view points. Differences always bring fantastic opportunities for learning and improvement. Recent research from National Center for Women & Information Technology (NCWIT) shows that diverse talent in the technology industry increases innovation, productivity, and competitiveness:

  • A recent NCWIT study shows that teams comprising women and men produce IT patents that are cited 26–42 percent more often than the norm for similar types of patents.
  • In a study of more than 100 teams at 21 companies, teams with equal numbers of women and men were more likely (than teams of any other composition) to experiment, be creative, share knowledge, and fulfill tasks.
  • Additional studies indicate that, under the right conditions, teams comprising diverse members consistently outperform teams comprising “highest-ability” members.

Anita Borg Institute for Women and Technology provides the business case for gender diversity:

The War for Talent – Remaining Competitive: Reaching out to technical women is crucial to a company’s ability to attract and retain the human capital it needs to succeed, and research shows:

  • The cost of filling the vacancy of a skilled technical employee has been estimated to be as high as 120% of the yearly salary attached to that position.
  • Despite popular beliefs about the impact of offshoring on hi-tech jobs, numbers show that the demand for high-level high-tech jobs such as software engineers has increased since 2000 and that offshoring has not slowed job growth in developed countries.
  • Companies are looking for technology workers with more experience and a broader set of skills such as leadership and interpersonal communication skills. Competition for these employees, combined with the drop of computer science graduates and impending retirement of the baby-boomer generation, has led to fierce recruiting competition among firms; nearly 300 technology executives surveyed identified identifying, hiring, and retaining skilled technical workers as their top concern in 2006.
  • Companies with effective diversity inclusion practices benefit from reduced absenteeism and employee turnover.

Women have the skill set for the new competitive demands of technical work

  • Companies agree that they need more technical leaders with varied skills such as interpersonal skills and business skills. 93% of technical leaders in a survey identified the building of collaborative networks in an organization as a crucial component of leadership. Women have the skills to meet the new demands of technological work both in terms of technical and interpersonal skills.

Women are paramount to User-Driven Innovation

  • Women influence 80% of consumer spending decisions, and yet 90% of technology products and services are designed by men. Including women in the technological design process means more competitive products in the marketplace.
  • The most innovative companies design products through user-driven innovation by integrating lead users in the design process. Women bring new markets and new technological applications to the design process and can market effectively to women, opening up new lines of business. Women of various ethnic backgrounds can furthermore open new international and ethnic markets.

Diversity brings benefits to an organizationís image

  • Companies with a diverse workforce generally benefit from a better image in the marketplace.

Diversity makes for better decision-making at all organizational levels

  • Group diversity leads to better decision outcomes, and this has been shown in a variety of settings,
    occupations, and organizations, and also applies to group task performance and to creativity and innovation. Diversity is beneficial because a variety of opinions, backgrounds, and thinking styles and their integration into the solution are what contribute to better decision outcomes.
  • Research has found a correlation between the presence of women in higher management and financial performance of the organization, as measured to total return to shareholders and return on equity.
  • A recent industry report estimates that by 2012, teams with gender diversity will double their chances of exceeding performance expectations when compared to all male teams.
  • Diversity is especially important and beneficial for problem solving and innovation tasks, such as is the case in technology.

Three weeks ago a read an interesting article on men and women in a Brazilian magazine called “Super Interessante”.

Cover of june's edition of a Brazilian magazine on men and women

Cover of june's edition of a Brazilian magazine on men and women

Some interesting facts from the article:

  • Women earn 75% of men’s salary for the same type of work.
  • 57% of the men negotiate their first salary. Only 7% of women negotiate their first salary.
  • Men prefer jobs with performance bonus and competition.
  • With friends, men talk more than women. However, when they are 1 year and 8 month old, women talk 2 to 3 times more than men.
  • Also, girls are stronger, since child death is 22% bigger for boys.
  • Women are 59% of the people who receives a university degree.
  • In 2010 women are the majority of the American workforce.

What can we do to improve this situation

Last week I watched a very interesting presentation entitled “Where Are All The Women?” by Erin O’Brien (@coolaunterin) via @sarahtarap and @dlbock that shed some light on the topic:

facts:

  • general US workforce: 47% women and 53% men.
  • computer and math occupations 26% women and 74% men. Women share is declining.
  • computer programmers: 22% women and 78% men.
  • open-source programmers: 2% women and 98% men.

possible explanations:

  • stereotyped computer programmer image:
    Computer programmer stereotype

    Computer programmer stereotype

  • a study in the university of washington where they introduced women into a computer science department classroom. If that classroom has images of startrek posters and videogame lying around women were less likely to show an interest in the computer science field. If that same classroom, still labeled as computer science classroom, has nature posters and phone booths lying around women were as likely as men to show an interest in computer science industry.
  • it’s a two way street:
    • women need to work to get into the field despite the stereotype
    • people need to work hard to recruit women

Some advice for those who are trying to attract women to work in their companies:

  • Don’t make your office spaces stereotypical. Fill your spaces with non-stereotypical images.
  • Don’t assume all women like shopping, the color pink, or panda bears. There’s not a stereotypical female programmer.
  • Don’t allow gender-specific job titles: mother, diva, princess, babysitter, etc. Use titles that speak to skill and attributes.
  • Women work one hour less per week, but spend twice as many hours on housework as men.
  • Women are not appealing candidates because of maternity leave, sick kids, school vacations, sick spouse. Hence, be flexible for ALL employees for family time.
  • Networking is essential to further the career and networking normally happens in conferences which involves social aspects and traveling. This can be hard for a woman in an environment dominated by men. Additionally, it is bit harder for women to travel.
  • Women tend to self-select herself out and to sell herself short. Organizations need to more flexible on their search for talent and women need to sell themselves more adequately. When men succeed they justify it with their ability and skill. When women succeed they justify it with luck. When men fail they justify it with bad luck. When women fail they justify it with low ability. Hence don’t reject a woman at the resume-level of selection. Give them the benefit of the doubt. Interview all of them even if her resume is not as good as some men candidates. She’s probably selling herself short.
  • Women receive shorter letters of recommendation and lower job performance ratings. So use objective measures of job performance (e.g., # of widgets). Don’t use reviews to determine pay increases.
  • 82 cents is not equal to a dollar. A woman gets paid 82 cents for every dollar a man gets paid for the exact same programming job.
  • Don’t ask women why there aren’t more women in programming. Read blogs, articles, etc. by women in the field.
  • Don’t ask a woman to speak for ALL women in the field. Ask men to speak to other men about the problem.
  • Don’t assume a woman works in HR. Assume she is a programmer.
  • Don’t point out the only woman in the room. Ask a woman how she got started in programming.
  • Don’t assume a programmer isn’t a “real” programmer. Ask her what her favorite project is / was.
  • Start them early!
  • Be careful with language. Women have a natural aversion to risk. “Let’s hack this” may sound dangerous to a woman while it sounds cool to a man.
  • Get involved with organizations helping women (.e.g., STEM – Women in Science, Technology, Engineering,
    and Mathematics
    .
  • Don’t ask women out that you work with.
  • Finally, inspire someone, guide someone, coach someone, mentor someone!

Checkout the full presentation.

Lessons learned

  • We need to recognize that gender diversity matters both because of its social aspect – equal opportunity to all people – and its business aspect – diversity impacts positively the bottom line.
  • After recognizing that gender diversity matters, we need to embrace the difference and work hard to improve this situation. Some suggestions on how to improve this situation can be seen in Erin O’Brien’s (@coolaunterin) presentation “Where Are All The Women?“. These suggestions were summarized above.
9 people like this post.

»  Substance: WordPress   »  Style: Ahren Ahimsa