Tag Archive | conflict

Diversity Is Really Freaking Hard

Background

I’m going to discuss an important topic that affects everybody in tech: diversity.

No, this won’t be some preachy post about how diversity is great and how you should be a better human being. Rather, I’m going to tell you about the things I’ve experienced working on diversity – particularly the interesting events of the last few days that happened internally at Stack Overflow.

It’s no secret that the tech industry is not that diverse. It’s mostly dominated by white males, with a few women and minorities making appearances. Those who do enter the industry as a minority often feel marginalized and excluded.

Of about 40 engineering employees at Stack Overflow, maybe 8 are not white men. We can clearly do better.

As you may have learned in my last post, earlier this year I was promoted to Engineering Manager at Stack Overflow (formerly Stack Exchange (formerly Stack Overflow)). One of my first projects was to work on diversity at our company. As a part of this goal, I was given the opportunity to create a new diversity page to showcase our efforts.

There’s a volunteer group that we have internally called the Diversity & Inclusion Panel (DIP). This group works to make Stack Overflow a more open, diverse, and welcoming environment.

There were some awkward feelings that came with taking the lead on the diversity page project. For one, I was a straight white male running a project about diversity, which might raise some eyebrows or make people feel weird/jaded. To mitigate those feelings, and also because I value their opinions, I took the approach of including the DIP in the creation and review of the page. My rationale was that by including a group of self-selected folks who are passionate about diversity, we could reach a solid page design that wasn’t biased by building it myself. To this end the DIP were consulted multiple times and ultimately had the final say on the copy of the page.

Diversity Page Goes Live

After a few months of iterating with designers and the DIP, last week we rolled out the new page. Here’s what it looked like in all its glory (please don’t critique it in the comments – if you do, you missed the point of this post):

Our Shiny New Diversity Page

Our Shiny New Diversity Page

I was excited that we had made progress on such an important and sensitive topic. I announced the roll-out to the DIP group with little feedback or response, which at the time I didn’t think much of. I also broadcast it on Twitter, with very few others from Stack Overflow doing as such themselves. Again, I thought nothing of the lack of engagement.

A few days go by with the new page rolled out where things are mostly business-as-usual from my perspective. And then, last weekend, something really interesting happened.

The Blog Post

An employee at our company wrote a blog post titled “Discussing diversity terrifies me” on their personal blog. They have since taken the post down – a decision they made themselves. The post described this person’s feelings about our new page and how it made them feel uncomfortable in ways that they couldn’t fully explain. This person also explained how they felt terrified to discuss diversity with anyone, ever – even their best friends. This was because of prior experiences at prior companies where the discussion went poorly.

I came across the post on Saturday night at about 9pm. It did not call out me or the page as doing something wrong; it was a way for this person to express some thoughts that were very important to them, but that they otherwise felt they could not bring up.

I Felt Wronged

Upon reading it, I was really pissed off. I couldn’t believe that this person, given numerous opportunities to shape the page as part of the DIP, had remained silent during the project. I couldn’t believe that they didn’t come to me or anyone else at work, and instead took to talking about their issues on their blog, in public, which at the time I felt served to embarrass me in front of the company. After all, they were given tons of opportunities to talk about it internally, so why didn’t they? I felt slighted and wronged. I selfishly felt that this was all a personal attack on my work. I wasn’t happy.

The Company-Wide Revelation

On Monday afternoon I had a private conversation with the person who wrote the blog post. We had a really constructive chat about how the person felt, and ways to improve upon the new page and make it more sincere and reflective of our true values and current workplace diversity. It ended on a positive note. Later Monday evening, I sent out an anonymous survey to solicit broad feedback from folks on how to improve the page. The plan was to iterate to a better version ASAP. Satisfied with trying to improve the situation, I went to bed.

On Tuesday I found myself in a few conversations about our new page. The people engaging me were mostly straight white males (not unlike myself) who all said something similar: “talking about diversity scares me to death” and “it feels like one wrong word and I’m fired.” These conversations continued until about 1pm, when a forward-thinking co-worker realized that we all needed to get on the same page. They brought the diversity page controversy up in our company-wide chat room for literally anyone and everyone to discuss. Many people jumped in and what followed, for lack of better description, was quite an epic conversation. It involved a lot of people from a lot of departments – both people who were visibly diverse and those who were not – and even included 4 executives. The conversation rolled on for a few hours and culminated in a few important outcomes:

  • The person who wrote the blog post felt very uncomfortable talking about diversity at all, with anyone
  • Their blog post gave a voice to many others who felt the same way but were afraid to speak up
  • The diversity page was making people within Stack Overflow uncomfortable

As a result of the company-wide chat, the new diversity page was taken offline.

I Felt Even More Wronged

Conveniently, all of this discussion happened while I was at the doctor’s office for a check-up. As a result of the timing I didn’t get to participate at all. When I returned from the doctor and read the chat transcript, I became very, very upset and angry. I felt betrayed by the company and wronged by almost everybody who participated in the conversation. In hindsight, I think that I probably would have said some things that I’d now regret had I been around to participate in the chat. Ignorance is sometimes bliss.

I was boiling over. Many unfair, selfish, and angry thoughts crossed my mind as I read the chat transcript. I thought things like “f*** it, I’m never touching another diversity project ever again” and “how could these people do this to me?” and even, for a brief moment, “what am I doing working somewhere where I’m undermined and treated unfairly?”

I called it quits a few hours early on Tuesday and had a few drinks of the alcoholic nature. I was fuming, and ranting to my wife, and otherwise upset about how I had been so wronged by the people that I was trying to help. I took some ibuprofen (for the impending hangover and headache) and passed out, unsure of what Wednesday would bring.

Worth noting, I don’t recommend self-medicating with alcohol when you’re upset – it’s a bad strategy.

This Wasn’t About Me At All

I awoke Wednesday morning with a clear mind and new perspective on the events of the past few days. I realized some really important things:

  • Absolutely, literally, none of this was about me. I was being selfish and making it about how I felt, when in reality it was about how we all felt.
  • We had created a diversity page that did a poor job of accomplishing our goals on diversity.
  • Taking the page offline was the right thing to do, because it was making a lot of people in our company uncomfortable. If it had this effect internally, it surely had a similar effect externally. In this case, the page existing was perhaps worse than having no page at all.
  • The person who wrote the blog post was completely in the right, and arguably did the right thing. The alternative was that if they hadn’t spoken up on their blog, nobody may have. This would leave everyone silently feeling uncomfortable.
  • The person who wrote the blog post felt uncomfortable speaking up about diversity at work. They talked about it on their personal blog to keep it outside of the company. This was an important revelation as it showed me that we have a serious issue at our company: people feel as if they don’t always have the right to speak up about difficult subjects like diversity. One person described it as “a manager’s word being law and difficult to contest.”
  • Nobody had been malicious at all. We were all trying to do the right thing, assumed the best of intentions in each other, and were simply expressing our honest feelings on the topic. Feelings are always valid.

Diversity At Stack Overflow

Through all of this I realized some of why diversity is such a hard topic for people to discuss: no matter what position you are in, you probably feel like you’re not entitled to participate in the conversation. When nobody feels like they’re able to talk, silence soon becomes apathy.

On the topic of diversity issues, apathy rules all. It’s a safe and easy play to do nothing at all. Taking a stance means meeting resistance and having conversations where everyone feels invalidated. Unfortunately, doing nothing enables and furthers the issue.

One of the mistakes that I made was not considering the emotional response of the new diversity page that we created. How the page makes people feel is the only measure of success. The people in our company felt that the page was insincere and made them uncomfortable.

Here’s the truth: despite what the page said, we’re not great at diversity. We have about 40 engineering team members, and only 4 of them are women. At most, 8 or 9 total are of a visible minority. We certainly have a diverse team in the sense that we’re located all over the world, but that isn’t how everybody defines diversity, and maybe isn’t even the most important form of diversity since those geographically diverse people aren’t necessarily marginalized.

It’s really easy to feel as if your company sucks at diversity when any discussion is met with frustration and hurt feelings. However, I am really proud of the fact that at Stack Overflow we are able to have these conversations. We had a company-wide discussion on how the page made everybody feel, and even though that discussion got extremely heated and many people felt many strong emotions, not one person made it personal. There were 4 executives in the conversation and nobody quit or got fired.

I’m thankful that one person had the courage to write a blog post and speak up about their overarching fear of discussing diversity. What scares me as a manager is the idea that people might feel as if there’s no channel to talk about things that make them uncomfortable. If people don’t express their concerns, they suffer silently. It was the actions of one person that saved us all from a much worse outcome.

Ultimately, we made a company diversity page that’s like every other company’s diversity page, at a company that prides itself in not being like any other company. We’ve identified that people at Stack Overflow sometimes feel like they are unable to speak up on difficult topics – both inside and outside of the company – and that’s something that we need to work on.

What’s Next

As I said earlier, the easy and safe play is to do nothing. We could leave things in their current state of no longer having a diversity page, but it would also be the wrong thing to do.

What we must do now is continue the conversation. We need to talk honestly about diversity and discuss the feelings that we have around it. We need to channel those feelings into a better diversity page that accurately reflects our company and how we feel on the subject. We need to admit that diversity is hard, but that we’re working on it. Most importantly, we need to assume the best intentions of each other and make progress together in all of our diversity initiatives.

I hope that in reading this, you feel inspired to start or continue the conversation about diversity in your workplace. Like many companies, we have a long way to go. It’s challenging, but as a co-worker said, “the hardest conversations are often the ones most worth having.”

How To Guarantee Dev Team Failure

The Problem

I think that most devs would agree when I state that the definition of success in the corporate world of development places less emphasis on “good” code and more emphasis on “working” code. Working code is code that can be released to production on or before the deadline, regardless of performance or even bugs in most cases. As a developer, you ultimately feel as if you’ve failed when you toil for nights on end to meet steep deadlines and churn out crappy code. As a business, however, you’ve succeeded when you hit the deadline. My experience tells me that the typical metric upon which development teams are measured is often not quality of code or unit tests or even performance, but instead ability to meet deadlines and deliver solutions to clients. You’ve failed when you do not meet the deadlines and thus piss off the clients/customers. Your job has become a veritable boolean result with the outcomes of true and false. Deadline met? True. Deadline missed? False.

Doesn’t it feel awful to be measured in such a binary way? All or nothing, success or failure, deliver or delay. These are the only outcomes according to the people who write and sign your paychecks.

The Conflict

Why does this happen? A little introspective thought brings light to the subject, at least for me. The reason for these types of metrics becomes obvious when you consider their source. You work for a company who pays you (often with I.T. seen as a cost-center or “money pit”) to accomplish things which the company can then sell to clients. You’re an expensive tool by which they accomplish their means. Though these companies often see software as a profit source, they see the means by which they get the software as an expense and cost. Kind of strange, really.

The problem begins at the very core of the organization; the structure of the company is the starting point for guaranteed failure. In my experience, the dichotomy that forms in most companies is “I.T.” versus “The Business” in a bout-to-knock-the-other-guy-out. The minute you create this relationship of opposing fronts, you’ve already guaranteed development failure. With competing and contrasting goals (the business wants to sell stuff ASAP while I.T. wants to build stuff properly which takes longer) it is not possible for trust to exist within the organization. The Business will not believe a word that I.T. says when it comes to estimates, deadlines, or things that need to happen to ensure stability of the product in the future (technical debt). I.T. will not trust The Business to make rational decisions when it comes to features, development timelines and ensuring product quality. The result is a boxing match where each side is trying to force the other into compliance. Now you have conflict. Conflict dismantles good companies.

The Measurables

The Business is used to tracking their sales teams by metrics like “how many calls did you make/receive today?” and “how many sales did you make?” and “did you make X sales by Y arbitrary date?” where Y could be the end of each month. These are things that they understand, and thus like to control. Ask your favourite sales person for their opinion on the metrics by which their success is measured, and I am confident you’ll find that most will sum it up as “the faster I sell things, and the more things I sell, the more successful I am.” This makes sense from an empirical, see-the-figures-on-paper-on-my-desk-in-my-executive-office point of view, but I bet that the sales person in this case is not loving their life. A constant push to sell more, make more money, and do more. Any success in the future just raises the bar for the success which must follow. It’s a losing scenario. Eventually, they either get promoted out of the trenches of sales or they move to another company, resetting the bar which has been set too high. This buys them another year or two of raising that bar, until they ultimately repeat the process again.

Sales people who are put under the gun in such situations often resort to employing any tactic that they can to reach their goals… One of these strategies is saying anything at all to sign the client up. “Sure, the software can create rainbows and unicorns, just sign on the dotted line!” they say. It’s unfortunate, because customers who are hooked into these contracts tend to be very unhappy with the product when they find out that the software does not, in fact, create rainbows or unicorns. Or even a colour wheel and horses. It doesn’t even come close.

In the above case, The Business fails to measure the things that, long-term, make you the most money: client satisfaction and relationships. A good sales person (they definitely exist) is one that keeps the client happy with rational discussions and promises, and who is very transparent about what can and cannot be done and why. A great sales person is one the client loves so much that they’ll keep using your product, even when a better product exists, simply because they fear losing the relationship. This client is a client for life (or at least a long while) and makes you a lot of money. But how do you measure “happiness” and “relationships” long term? It’s a hard problem. Dating sites have been trying to solve it for over a decade. The Business will likely not dedicate the time and resource to do so themselves. So, they measure phone calls, sales, and other crappy metrics to ensure that the sales team are doing their job.

Here’s where we get back to the topic: developers and failure. The Business, who in most cases pays I.T. to create things to sell, employs these same arbitrary measurements when grading development teams. They often only know how to see success as a measured outcome of facts, and so they create the only measurements that they can empirically apply: features and deadlines. Does the dev team build all of the features and hit the deadline? Great. Do they not? Not great. These measurements themselves are acceptable (even good), but the combination of them (lots of features on short deadlines) is the problem.

The Money Talks

Where it gets tricky is in the realization that “show me the money” is how business ultimately tends to run. The sales people very overtly make the money, so they are seen as successful and important people in the company. The dev team also makes money, but is perceived to cost money, and they are seen as a cost-center that must be carefully weighed and measured to avoid excessive spending. What this leads to is an unhealthy practice of allowing sales people the freedom to employ any tactics necessary to land sales and make the money. In a business such as The Business as described, your life as a developer begins to suck.

To close the deal, the sales person will often promise the client almost anything about the software that you develop. They may promise new feature X by the end of the month, they may even promise 10 new features by the middle of the month. Whatever makes the client sign on. Then, the client says let’s rock and your quality of life drops sharply.

The very next thing that happens is The Business casually tries to confirm what seems obvious and even mandatory to them. “So your team will have these 10 things ready to go by the 15th, right?” they say. “This is a million dollar client, and it would be horrible if we lost them because you couldn’t deliver!” and now the pressure is on to do the nearly-impossible in virtually no time.

The dev team might try to politely push back and say that this is practically impossible, but The Business sees the dollars on the dotted line and will not listen. Flip the kill switch. Forego the QA time, all developers must focus on all of these features, day and night, so that the deadline can be met. Why? Because that’s how the team is measured. If the team doesn’t hit that deadline, they’ve failed and the million dollar deal is lost with the dev team seemingly at fault. Developers don’t want to work extra? Order in pizzas and promise them time-in-lieu as soon as the deadline is over with. Note that they will likely never actually see this time-in-lieu because right after this deadline will be the next one, with similar outlandish expectations and even tighter deadlines. And after that, another one. And another one. And the cycle will probably never end.

The Mad Production Dash

So, as the developer, you develop it as fast as you can. The code starts to resemble Frankenstein as you tack on bits and pieces to make it work ASAP. You subdue your ego and uneasiness about the quality of code by commenting // HACK: undo this crap later everywhere. Somehow that makes you feel better as it creates the slight glimmer of hope that eventually you’ll have enough time to come back and undo this monstrous pile of garbage. But you never will get that time, because the next deal is coming down the pipe. And so the code becomes worse. Your development effort completes 1-2 days before the arbitrary sales deadline, and after your QA team flips their lids on having 48 hours to test 1000+ hours of work, they do “critical path testing” to make sure it at least does something correctly and certify it as “good enough.”

The team releases to production early in the morning of the deadline day, and though it takes 5 hours because there are 17 untested things to fix on-the-fly (and realistically they have no option to abort the release or roll back because the consequences will be dire), they eventually shove the hacked up code out the door and declare it done. The Business shows their appreciation in the form of a short, impersonal e-mail that doesn’t name any person of achievement specifically. The development team is feeling underappreciated and pissed off.

What does the future hold for such a company? The code will probably spiral into bug-filled oblivion until it can’t do anything correctly or in any reasonable amount of time. Despite the weeks and months during which the development team pleaded with the business for time to clean up the technical debt, they are brushed off because taking time off of features loses clients and thus money. Then, as it starts to come crashing down in production, they suddenly beg the developers for a quick fix. “Do whatever it is that needs to be done!” they plead as they see their sales going down the drain. And now, because it is on fire and burning to the ground, the dev team is finally given a moment to pay back some of the technical debt that has been accrued during this vicious cycle. Repeat.

The Solution

When a dev team has no say in the deadlines of the work they must do, they will usually fail. And when they are set up for failure from the start, they will likely get tired of being blamed for the problems without ever being given the time to devise the solutions. This leads to bad work culture, high turnover, and low productivity.

The way to guarantee dev team success is obvious at this point. It’s really as simple as trust between I.T. and The Business. They must keep each other in the loop as stakeholders. The Business has no product without I.T. and I.T. has no job without The Business’s clients. It’s a mutually beneficial relationship and it should be treated as such, rather than mutually parasitic.

A good company’s sales team will often consult with I.T. prior to promising any dates and deadlines when unknowns are involved. It is practical to ask the people responsible for a task how long it will take them to complete a task. This is much like how you might ask a waitress how long it will take for the food to arrive or a painter how many days they need to paint your home. This is a positive and productive discussion. Hallway conversations should become commonplace: “Hey dev team, I’ve got a client who wants to sign on but not until we build X, how long will that take?” The reply is as easy as “We’ll discuss it as a team and send you an estimate with some assumptions to confirm with the client” and just like that there’s a great working relationship that practically guarantees success. The team knows what work is coming, and also knows how long they have to complete it.

The Correct Measurements

If a dev team continues to fail in an environment where trust exists, then that team is likely not competent. They either cannot estimate correctly or cannot deliver within their own estimates. Sometimes devs suck at estimating because they’ve been making estimates under the oppressive sales gun for so long that they’ve effectively forgotten how to give themselves a fair amount of time. The blame for this remains entirely on the dev team, and they (or The Business) must repair the situation quickly and effectively to maintain the mutually beneficial relationship based on trust. As The Business owes I.T. input into the deadlines, I.T. carries the burden of being fair, accurate, and responsible with those deadlines.

Assuming that The Business now has a competent, skilled dev team, the question turns to the customers. If the customers do not like the estimates given to them, this may cost the company sales. Perhaps the customer wanted the impossible and The Business is giving them a dose of reality. Perhaps The Business does not want such a needy customer and they’re in a situation to be able to afford to tell them no thanks. Perhaps The Business realizes that the client’s request is reasonable but the timeframe of the estimate feels a bit long. In that case they can ask I.T. why. If the answer is not sufficient and justifiable, then perhaps the dev team is still not competent. No dev team should be let loose without checks and measures on productivity, but those metrics should be reasonable.

Ultimately, if you want to guarantee the failure of a development team, simply promise features to clients and customers without ever asking for (or trusting) the input of the team that is actually going to build those features. It’s just like telling the waitress that your food must be on the table in 10 minutes, without first asking the cooks how long it takes to safely and properly make it.

If this situation sounds familiar, try talking with The Business about it. Try to help them see it from your point of view. Ask them “how successful would you be if I demanded that you sell 20 new clients by Friday?” and perhaps some light bulbs will start to go on. Ultimately, we as developers often know nothing about sales and have no business dictating their measurable work expectations. They similarly have no business dictating ours, but a relationship of trust can be built to allow us all to work together and accomplish great things.