ThoughtWorks finally moves “product over project” from trial to adopt!
Nov 29th, 2015 by Joca

ThoughtWorks is a well known software development company which is always one step ahead of the rest of the software industry. Many people who contributed and continue to contribute to our industry are – or were – ThoughtWorkers. Martin Fowler, Jeff Patton, Neal Ford, Jim Highsmith, Rebecca Parsons, Ola Bini, Jim Webber, Luca Bastos, Paulo Caroli, Claudia Melo are just a small sample of people who work – or worked – there and have contributed a lot for the evolution of the software industry.

Since 2010 they publish a document called Technology Radar where they talk about their view on techniques, languages, platforms and tools for software development. This view is based on the experience from their consultants who work on a variety of software development endeavours from customers all over the world. They classify the techniques, languages, platforms and tools in four main categories:

  • Hold: when placed in this band, the item may be of interest to ThoughtWorks and others in the industry. However it is their opinion that the item is not ready to invest significant time and resources in which to build experience.
  • Assess: a technique, tool, language or platform that moves into the assess band of the radar is something that they believe is worth exploring with the goal of understanding how it will affect the technology impacted dimensions of your enterprise.
  • Trial: having established a radar item as something worth pursuing, it is important to understand how to build up this capability. Enterprises should look to trial the technology on projects that have a risk profile capable of taking onboard a new technology or approach.
  • Adopt: is the final stage that is of interest to them on the radar. Here they feel that the industry has begun to move beyond the trial phase and has found the proper patterns of usage for an item. An item may also appear in the adopt band if they feel strongly that the industry should be adopting a radar item now, rather than going through a more gradual adoption approach.

In May 2015 I was quite pleased when May’s Technology Radar edition brought “Products over Projects” as new technique and already recommended it as TRIAL. This showed that ThoughtWorks started to believe that software development should not be viewed as a project with a clear start and finish, but rather as a product, developed to support business processes of the owner of the software. This software will have a long life cycle, so long as the life cycle of the business processes it supports. For this reason, software development should not be viewed as a project with a predictable end, but rather as a product, a tool that will support the business processes for as long as the business processes exist.

I wrote about the differences between a product and a project back in 2011 and the more I work with software development, the more it get clearer to me that we should manage software development as a product, with a long lifecycle, with an unpredictable end. For this reason product management is so important for software development.

From trial to adopt

When I saw the November 2015 Technology Radar edition I was even more pleased when I saw that ThoughtWorks decided to move “products over projects” from trial to adopt. Doing so they now consider software product management as a technique that they feel strongly that the industry of software should be adopting in order to increase the chances of success of their software. Here it is in their own words:

We’ve long been championing the idea that thinking of software development as a project – something budgeted and delivered during a limited time slot – doesn’t fit the needs of the modern business. Important software efforts need to be an ongoing product that supports and rethinks the business process it is supporting. Such efforts are not complete until the business process, and its software, cease to be useful. Our observation of this products over projects approach, both with our own projects and outside, makes us determine that it is the approach to use for all but exceptional cases.

Certainly this will help people all over the world in creating better software, which will meet the needs of their customers while helping the software owners reach their objectives.

This is a great step forward for the software industry! This is great step forward for software product management! \o/

10 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:



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?

11 people like this post.

Why the hurry to launch an MVP?
Oct 7th, 2012 by Joca

I mentioned earlier that I was starting:

a new project called “The startup guide: how to create and manage profitable web products”. It’s a blog that will eventually become a book where I’ll explain how to create and manage a web product with a profit.

Well, I finished writing the book which is called “The Startup Guide: how startups and established companies can create and manage profitable web products“. The book is focused on how any type of company – no matter if it’s a startup or an established company – can create and profitably manage a web software. All it’s content is available at the “Guia da Startup” blog. It’s currently in Portuguese so it’s a good opportunity for you to practice reading in a new language. If you are not up-to-date with your Portuguese skills, there’s the option of using Google Translate but some meaning may be lost in translation. For these reason I intend to translate the content into English eventually.

One of the most popular posts from this blog is about the reasons to make fast the first version of your product. Why do we need to make an MVP? Why not wait to have the product with more features to launch it? Herb Kelleher, co-founder and former CEO of Southwest Airlines has a famous phrase to motivate people to do things:

“We have a ‘strategic plan.’ It’s called doing things.”

This “strategic plan” can be translated into the #jfdi hashtag which means something in the lines of “just focus and do it” or “just freakin’ do it” (polite form).

But why the hurry? Why can’t we keep working on our product until we feel comfortable it has all the features we believe are needed to solve the user’s problem?

Well, there are 3 main reasons:

Reason #1: The moment of truth!

The longer you take to put your product in front of real users, the longer you take to start getting feedback from real people to know if you’re on the right track. And what’s even worse, you’ll probably be giving too many steps in the wrong direction.

A software is supposed to solve a certain problem of its users. You will not know if you have built a good product until the product is used by real users and it actually solves one of their problems. The longer it takes for this to happen, the longer it will take for you to know if your product is or is not the solution for someone’s problem.

And if it is not, what should you do? Change, adapt and present it again to real users! The sooner you know that what you’re developing is not on track, the better, because you’ll have spent less time, energy and money moving into the wrong direction.

Reason #2: Featuritis

There’s a limit to the number of features an user can understand. When we present a software full of features to a potential user, instead of providing her with a possible solution to one of her problems, we may end up creating a new problem for her. Kathy Sierra, a well known software development and user experience instructor, designed the Featuritis Curve that illustrates in a clear and fun way how user satisfaction diminishes as we increase the number of features of a product.

Reason #3: ROI

The longer you take to put your product in front of real users, the longer it will take for you get some revenue and the longer you’ll have to invest from your own money or investor’s money. Below is a typical return on investment chart. While you don’t launch your product and don’t have revenue, all you’ll have are costs, i.e., you’ll be in the investment phase of the curve below. This situation will only change when you get some revenue and this revenue pays your monthly costs. This is the monthly profitability phase in the chart. Only after a few months in the monthly profitability phase you’ll be able to get to the return on investment phase. It’s a long way:

Now take a look at the chart below. If you decide to delay your launch in 3 months, this can delay your return on investment in 6 months! Are the features that you intend to implement in those 3 months you are delaying the product launch worth the 6 months delay to get to the return on investment phase?

On the other hand, if you are able to launch 3 months sooner than what’s described in the first chart, you’ll get into the return on investment phase 6 months sooner. Isn’t that worth figuring out how to launch your product faster?

If you’re not embarrassed…

There is a famous quote by Reid Hoffman, founder of LinkedIn, which really resonates with the MVP concept:

“If you are not embarrassed by the first version of your product, you’ve launched too late.”

To illustrate this quote, here are some print screens of early versions of well known software products:

Google in 1998

Twitter in 2006

Linkedin in 2005

Facebook login screen in 2005

Facebook in 2005

Next post

Last year I decided to run a lean startup experiment. Would it be possible to build a software and market it without using Locaweb’s marketing power? The result of this experiment is a calorie counter web product with more than 17,000 registered users in less than one year of operation. In my next post I’ll explain how I built the first version of this product in 10 days.

14 people like this post.

Why before how
Aug 7th, 2012 by Joca

This weekend I was at QCon São Paulo, a great conference made by developers for developers.

In this conference I talked about “Guia da Startup” (Startup Guide), a blog (in Portuguese) that became a book (also in Portuguese) about product management lessons for web startups and for non-startups with web projects. I have plans to translate the content of this book to English and post it here.

Martin Fowler (@martinfowler) from ThoughtWorks gave the first keynote. At a certain point he used an interesting quote to introduce the topic of good design and technical debt.

I commonly come across developers who are frustrated because “management want more features, they don’t care about quality”

The quote got my attention specially because as a developer talking to developers in a developer conference, Martin focused on the part of the quote that normally drives the attention of all developers, the “how” part. He focused on the “quality” word to explain how important it is to have good design to avoid technical debt so developers can add more features more easily. As I’m more focused on the product management side of software development, as soon as I read the quote, I focused on the “why” part. This motivated me to create a new slide in my presentation about product management practices:

When I heard the quote, my focus was directed directly to the word “features” and my first reaction was asking “Why is this feature being requested?”

When we are asked to implement a feature in a software, the natural reaction is to think how this feature will be implemented. However, we need to give a step back and understand what we are trying to achieve implementing this feature. What value this feature brings to the software users? What value this feature brings to the software owners? Every new feature, no matter how small it is and how simple it is to implement, creates complexity in our code. What’s the value we expect out of this additional complexity? This is a question that not only a product manager should ask, but every developer who is asked to implement a feature should ask.

So my recommendation to every developer who’s asked to implement a feature is, before rushing to figure out “how” a feature should be implemented, question “why” this feature is being asked. This will help you understand the importance of the feature and help who’s asking the feature to reassure the motivation behind this feature.

16 people like this post.

You need to talk with real users in order to build good software
Apr 12th, 2012 by Joca

I was reviewing ThoughtWorks latest version of their Technology Radar, which is a great source of information to help you know what’s hot in terms of software development and IT management, and notice it doesn’t mention Product Management (or you can call it Product Ownership) and put Experience Design (XD) only at the “assess” sector of the technique area of the radar.

In my view, Product Management and Experience Design are techniques as critical to successful software projects as DevOps, Continuous Delivery, Testing, Agile and Lean.

  • Product Management role tells what needs to done and in what order.
  • Experience Design role tells how what needs to done should be done, from the user experience perspective.

It is quite difficult to develop good software without those two roles and their techniques. Both should be in the “adopt” sector of the technique area of the radar.

Product Management is not only for systems that will become a product, but for any system, since any system will have users. The Product Management role is the link between system users and the team who will build the system. It is different from the Business Analyst role which is more focused in the business and the owners of the system. And its different from Experience Design role which is more focused on how a user interacts with a system.

The Product Management role is responsible for talking with real users of the system, understanding the pain that the system is supposed to solve for these real users and help define what needs to be developed. Note that a system may be owned by a company, like a ticketing system or an ecommerce system, and this company who owns the system will ask for a certain set of features so they can reach a certain business goal, but the requirement gathering is incomplete if we don’t listen to the real users of the system who normally are customers of the company who owns the system.

If you have a great group of developers, QAs and BAs, all veterans in using Agile, Lean, Testing, DevOps and Continuous Delivery, all of that is useless if you are not able define what is the minimal set of features that can create value for the customer in the first release. And subsequently define the minimal features to be developed and deployed that brings greatest value to real users. The Lean Startup movement calls it MVP (Minimal Viable Product). Mark Denne and Jane Cleland-Huang, authors of Software by Numbers, first published in 2003, coined another term for this minimal set of features. They call it MMF (Minimal Marketable Feature).

The Agile Manifesto says that we should value “Customer collaboration over contract negotiation” and set as it’s first principle that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. The issue with these two statements is that it assumes that the customer who is the owner of the system knows what is “valuable software”. However, the customer normally knows what is “valuable software” for him, i.e., he knows what are his business goals that they want to achieve with the system. The problem is that the customer doesn’t know his own customers/users enough in order to define the requirements upon what a system should be developed, i.e., the customer doesn’t know what is “valuable software” for his own customers/users.

It is the Product Manager’s role to understand the users of a product/system, the problem the users have, and should bring this information back to the developers and experience designers so these three roles can jointly come up with a product/system that solves the users problem and, at the same time, meet the system owner’s business goals.

What do you think? Do you agree? Disagree? Share your comments below! 🙂

18 people like this post.

What is Product Management?
Jul 3rd, 2011 by Joca

DDD (Domain Driven Design) has a very powerful concept, so powerful that it is the first concept presented to anyone who is initiated in DDD, Ubiquitous Language:

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

source: http://domaindrivendesign.org/node/132

It’s a way to guarantee a shared understanding of the main terms used in a domain.

I’ll start to write more about Product Management here, so I felt the need to define Product Management prior to writing more about it.


Prior to defining Product Management, let me define product in the software development industry:

Product is any customer facing software system.

A customer facing software system is not necessarily a system which drives revenue through subscription or on-demand use. A system like a newspaper portal can be considered a product. The revenue from such a system probably will come from ads. An internet banking is another example of a customer facing system who would benefit from product management. It doesn’t drive direct revenue but it helps decreasing cost of physical bank offices.

Product Management

And here goes the Product Management definition:

Product Management is accountable and responsible for everything from high-level objectives to the details of the user experience of a customer facing system. It’s the connection between the business strategy and the customer through a software system.

3 people like 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.


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:


  • 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