February 28, 2015
Fair Startup Salary Compensation
I was having lunch with my friend in South Park. Earlier that week, he texted me about how we calculate our team’s salaries at TINT. He wasn’t sure if he was getting paid fairly at his startup and wanted to use TINT’s formula as a data point to figure it out. His questions sounded familiar because they were the same questions we asked ourselves when we set up our salary formula! The most important question being: “What is fair compensation for working at my startup?” As cofounders of TINT who’ve created a transparent salary structure that is now implemented for more than 20 employees, Tim, Nik, and I have collectively spent hundreds of hours discussing the answer. Here are my thoughts:
Before we start, we should address the question that was the first question my friend asked: “Is it fair to even ask?” e.g. Is it immoral to be that guy, the squeaky wheel that gets the grease? At TINT, we’ve solved this problem by being transparent, but my friend made me realize that not everyone has that luxury. From stories I’ve heard from other friends, it’s important to ask the question, especially if you don’t have transparency.
Another friend who works at a large undisclosed company in San Francisco told me about how her manager secretly offered an intern a higher salary than hers, even though she’s been working with the company for the past 2 years. Remember that asking the difficult questions about compensation may be the only way to move up. Don’t feel guilty about negotiating.
Fair compensation depends on 3 main factors, which are:
- Is it fair in relation to other people on your immediate team?
- Is it close to market rate?
- Is it fair to YOU?
At companies with closed salaries, the answer is usually off the table, and even asking the question can feel inappropriate. However, if you can find a way to ask your colleagues in a socially appropriate manner, you should learn more about how others are being compensated. Afraid of repercussions? In the US, the National Labor Relations Act makes it illegal to fire anyone because they shared their compensation within the organization.
Managers have long used salary information asymmetry to try to keep salaries as low as possible, hoping that employees will keep their heads in the sand. But salaries never stay secret forever. It’s a liability for organizations that hide salaries from employees, which makes it even more mysterious why the practice is mainstream. If you are still feeling weird about asking, read these two comment threads on Hacker News here and here.
Is it close to market rate?
Luckily, answering the second part of the fairness equation is easier than the first. There are a variety of resources to give you a general estimate and range.
The challenge in figuring out your market rate is that every company is slightly different, and every role varies as well. Your own market rate will likely be based on:
- Location / cost of living - Wolfram Alpha Cost of Living Calculator is a great resource for this
- Company size/risk - Riskier businesses will usually involve sacrificing salary for equity. But you’ll have to judge whether the potential equity value, increased ownership and other perks of working on a smaller team will outweigh the sacrifice.
- The role’s growth opportunity - If the role could be a valuable stepping stone in your career, it could possibly be worth a sacrifice in salary.
- Job perks - Free lunch, 401k matching, mandatory vacation policy, and other perks should be included in your calculations regarding the total compensation package.
Is it fair to YOU?
The third part of the fairness equation is the most interesting because it is both the most personal and also the most important component of the equation. It encapsulates your current situation as well as intangible factors that can make the biggest impact in your day-to-day work life:
- “The Happiness Factor” - A totally subjective value that depends on you. It represents how happy you would be working on this team because of the company’s mission, the people on the team, or the flexibility it’s structure allows. For many people, this is the most important factor.
- Your potential growth opportunity - If you could grow into a role at an accelerated pace, management may be willing to pay more.
- Your skills - Do you bring anything special to the table that few others could? List them out, and don’t be shy about bringing them up. An angel dies every time a talented but quiet employee gets screwed by their management.
How do I figure it out?
The resources below will give you a range and you will tweak that range yourself based on the conditions above.
The strong point of this chart is in how it visualizes the ranges of compensation and the ways it allows you to filter down into its dataset via role and company size. Just keep in mind that sometimes the data available is small, and that many other factors such as the Happiness Factor are not included in the compensation.
Although it’s filters aren’t as good, Angellist has a larger and more timely dataset than Wealthfront, and is another great place to begin exploring compensation ranges.
This is a great article if you’re wanting to convince management to adopt a more transparent approach to compensation. It reveals that many large companies do attempt to make some effort to make their compensation transparent, and that even the biggest names in the startup world recognize the fact that good compensation structures are founded on openness and formula.
This formula, from Buffer, that Tint used as the basis for our formula, and serves as a great example of one startup’s salary structure.
Did you know that Wolfram Alpha can give you a cost of living index between two locations and visualize it? Pretty handy to figure out how location influences your salary range. Sometimes it can make a huge difference!
Quora has an active community discussing startup salaries and the plethora of questions surrounding them. A great place to browse and explore, there are well-written answers to questions ranging from “Is it worth working at a small startup for no salary but for equity?” to “What technology skill set pays more in Silicon Valley: front-end, back-end, mobile or user experience?”.
The worst thing you can do to yourself is to voluntarily remain ignorant about how fair your salary is. I guarantee that if you remain ignorant in a closed-salary organization, your salary will end up being unfair, maybe even less than the intern’s. Unfortunately, most organizations would prefer you to stay ignorant. Educate yourself and fight back against information asymmetry. Or even better, work for a company like TINT that prides itself on fair compensation and implements innovative compensation structures such as monthly company-wide bonuses. Your most valuable asset is yourself, so don’t let people have it for less than you deserve.
January 14, 2015
“Move fast and Break things” (MF&BT) The company mantra is as common in the Bay Area startup scene as a Chrome backpack. Why? It captures the essence of why startups run by 20-somethings in hoodies can make headway into markets monopolized by Fortune 500 behemoths. More generally, it describes why the Silicon Valley tech industry has thrived in the last half century. If you are involved in tech, it defines the culture here: Take risks. However, the phrase has become so common that seeing a startup poster with MF&BT has become the equivalent of a boat of rowers paddling above “TEAMWORK”. Plenty an engineer has worked with a team that espoused the notion without success. The thing is, it’s not enough to tell employees to MF&BT and expect a faster MVP in the same way that it is meaningless and silly to tell people to increase their “TEAMWORK”. These phrases become vapid in the mouths of management who have forgotten the hard work involved in creating human and computer systems that naturally embody these ideals. The mistake is in thinking that these behaviors are the root of why some startups are successful and some are not. It is a mistake to aspire to these ideals without understanding that teams MF&BT not because of a poster in the break room, or because management told them so, but because that is what naturally comes to them. Some teams just naturally MF&BT, others don’t. But why? Teams that MF&BT:
- Are not afraid of repercussions when they break things
- Quickly learn lessons when things break
- Can “unbreak” their systems with minimal effort
To make this happen, they are usually good at creating policies and cultivating workplace habits that focus on feedback, learning from failure, and fault tolerance. Let’s examine these in more detail:
Employee feedback systems are boring, unappreciated, and hard. Creating a culture that encourages everyone to give feedback everyday is even harder. But doing so ensures that everyone can feel safe when they break things and know that it is sanctioned within the group.
- When someone has a great idea, let them know! Feedback doesn’t just mean negative feedback. Positive feedback increases morale and helps communicate what everyone wants to see more of.
- Cultivate your ability to give constructive criticism. This is a difficult skill that can take a lifetime to perfect, so start today! When having to give criticism, approach it as a challenge to improve your skills instead of an uncomfortable task to get over with quickly. There is nothing that you can read that will improve your skill here. Instead, find people who are known for giving good feedback and watch them. Then, find every opportunity you can to practice what they preach. I’ve found that people who are good at constructive criticism are great listeners, empathizers, and instinctively know how to walk the fine line between being realistic and demoralizing.
- Make feedback a regular process. At Tint, we’ve instituted monthly feedbacks where every employee requests feedback from at least 3 others in the company, and we take company time to introspect and write thoughtful feedback about what we like and what we want to see improved professionally.
2. Learning from failure
Creating policies that allow people to examine failures without blame.
- After every failure whether it’s a missed sales quota or system downtime, gather the team and figure out what went wrong, without blame, without shame. Etsy has a great blog post on how they conduct their blameless postmortems. The most important thing is to NOT ignore failure and to NOT point fingers.
- Write down what went wrong, why it went wrong, and what was learned, and email it out to everyone on the team. It helps everyone understand that failures are okay as long as we learn from them and helps spread knowledge.
- Write blog posts about your most notable failures. That way the community at large can see how you fixed the problem. You’re probably not the only one that failed!
- Create a fail wall at the office! You can see from the photo above the Fail Wall created by Spotify engineers. They have a great video series on their engineering culture that describes how they promote failure.
3. Fault Tolerance
Being able to easily tell when things go wrong and being okay with changing direction quickly is easier said than done. For some occupations, it’s not even possible. Luckily, it’s probably possible for you.
- Aspire to having great continuous integration - This means having high test coverage, fast build times, and as much automation as possible. Obviously, this takes a lot of work. But the faster it is to test code, the faster it is to write code.
- If your team is large enough, aspire to have innovative continuous integration. Github’s ChatOps is a great example of how far operations can be taken.
- Be disciplined about ROI. At TINT, we used to not formally measure the impact of going to social media conferences. However, we realized that without measuring impact, we can’t discern whether it was worth it or not.
- Leadership should encourage experimentation. If someone has an idea that they think could improve the process, but involves some risk, they should be given the freedom to try it out! Teams that experiment naturally fail more (in a good way), and failing more will make a team naturally more fault tolerant.
None of these techniques make for a sexy inspiration poster, but iterating on HR surveys for employee feedback are just as important, if not more important, as how many features get shipped every month. Ironically, MF&BT requires the opposite of recklessness. It requires attention to detail and more importantly, discipline.
January 4, 2015
I did an analysis of my transaction history for 2014 to try to dig up answers to a question that has been in the back of my mind all year: How am I spending my money?
In the spirit of radical transparency, here are the numbers.
- Paychecks: $75225
- Savings: $39713
- Savings Rate: 52.8%
- Rent: $9600/yr
- Average Rideshare Spend: $121/mo
- Average Total Transportation Spend: $252/mo
- Big costs of 2014:
- Equity: $7096.61
- Personal Debts: $2300
- Trip to Chicago: $635 + $608 flight for 2 = $1243
- Trip to Denver: $595 trip + $262 flight = $857
- Trip to KC: $514 trip + $345 flight = $857
- Total 2014 Subway Spend: $172
- Average Subway Meal: $6.10
- Total 2014 Lee’s Deli Spend: $389
- Average Lee’s Meal: $8.84
- Approx. Calculated Food/Discretionary: $876/mo -> $29.2/day
Conclusions and Goals
After taking income and subtracting savings, travel, transportation, and unexpected large costs, the remainder comes out to about $876/mo, which is $29.2 a day in food and discretionary spending. If I were to reduce this by 30% and save it, this would come to around three thousand dollars, which would increase my savings rate by only 4%, and given that a 30% cut in discretionary income would involve changes in my lifestyle, I would say that I did a good job this year of managing my money
appropriately. What this analysis says is essentially that my food and discretionary (not including travel) spend comes to use 13% of my annual income, which I am comfortable with.
Total travel spend this year comes down to approximately $3.5k, which is about 5% of my income, which I see as too little. In 2015 I want to travel more, and aim to increase that percentage to 7% which would correspond with a large trip every quarter.
As for savings goals, my goal is to continue to avoid lifestyle inflation and exceed a savings rate of 55% for the next year. If no large unexpected big costs occur, then both my travel and savings goals should be attainable. If some unexpected costs come up as they always do, I will probably cut into my savings rate rather than travel just because I may only have the next decade to travel with true freedom. Another goal for this year is to find a way to put more time into volunteering and philanthropy as I know many people don’t have the opportunity
to pursue financial independence.
December 3, 2014
My monthly self improvement challenge this month was to reduce low quality info consumption. More specifically, reduce the time I spend on Hacker News, Reddit, and other news sites. Why?
- Value: Although entertaining, the content is ultimately offers little value after being read.
- Time: Too much time spent passively reading, easy to “veg out”
- Opportunity Cost: There are many higher value things to read that I would personally feel more gratification reading.
How did I go about doing it?
Some interesting numbers:
- reddit, HN, medium, vanity fair, chow, sfgate, nytimes: Top distracting sites in October
- 10 hours -> 4 hours: 60% reduction in time spent on distracting websites from October to November
- 63 hours -> 64 hours: negligible change in time spent doing software development
- So over the course of the month, I added 6 more hours to my life by just reducing the time I vegetate!
The hardest thing was to stop the habit of opening a new reddit or hacker news tab during any downtime. It was practically muscle memory! I found myself opening and immediately closing tabs many times a day for the first week. However, the knowledge that my performance was being monitored by RescueTime helped keep me going.
One thing I anticipated was that I would be less up-to-date both in local and technical news. However, I was surprised to find the funniest or most important content being shared in the company chatroom anyway, filtered and curated by my friends. This didn’t end up being as large of a problem as I originally anticipated.
In the end, I felt more focused and able to direct my energy toward more difficult media consumption goals. I got halfway through a book that I would not have picked up if I didn’t do this challenge. I believe that it’s worth continuing this challenge into the future and hopefully I’ll have the discipline to do so.
- Write down a list of alternate content to consume in advance.
- Download books that you’ve been meaning to read and on your phone so you’re not languishing in the
- Track yourself using RescueTime both as a motivation tool and to measure your performance change.
November 1, 2014
In 1975, Frederick Brooks wrote a book on software engineering that is still applicable today in 2014! That book is called The Mythical Man Month and I found myself relating to many of the software-related scheduling and planning issues Brooks encountered almost half a century ago. Below are some of the key ideas I found the most compelling:
Programmers are naturally optimistic and programming is a tasks that lends itself to optimism.
Brooks argues “All programmers are optimists… Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal.” which leads to a false assumption that engineering tasks will take only as long as it ‘ought’ to take. However, any software development effort usually consists of many tasks chained end-to-end. The probability that every single one of them will go well is almost zero considering the perfection necessary as a programmer. Considering the volume of nitty frustrations I encounter everyday I definitely relate to being an optimist and have observed others and myself misjudge how long things will take due to this optimism.
1/3 planning 1/6 coding, 1/4 component tests, 1/4 integration tests
From my anecdotal evidence, this breakdown for how software time is spent is spot-on. Almost all of the engineering tasks that have been underestimated at our company have not taken into account the amount of time needed to properly test and integrate the system before it is production ready. Much of the reason is because we (the engineering team) are transitioning from “startup-mode” where we didn’t need as adequate testing because we had fewer customers. More customers find more bugs, so our acceptable threshold for stability has increased. And with it, the effort spend testing. I’ve just recently started to integrate testing into my estimates and so far both quality of product is higher, and target completion dates are more accurate.
**The Mythical Man Month: More people doesn’t equate to faster completion. **
Consider the following 2 graphs:
The first one shows just how difficult it is to maintain communication among more than a few people. The second illustrates how many months a project will take given the number of people on a team. Organizing work around a complex task is difficult with more people involved. But just how much more difficult did not dawn on me until I saw it visually. This bolsters my belief that features should be owned by two people or less who serve as a hub for collecting the knowledge necessary.
The Second System Effect: The second system you build will tend to be overengineered due to pent up desires
We are in the beginning stages of building parts of a second system, so we have not witnessed this yet. But after reading this chapter I will be more vigilant to make sure every part of a spec has solid business value, and to watch out for costly unimportant components.
Better to extend the schedule than release a half baked product
Brooks uses the analogy of an omelette as a delayed software project. You can either spend more time cooking it properly, turn off the heat and serve it raw, or turn up the heat and burn it. However, from my experience it is actually more effective to use less egg from the start. I actually disagreed with this point because you can better hit a target by removing non-essential functionality from a feature early on in the planning stages, which is a better alternative than extending the schedule or releasing a bad product.
Conceptual integrity is the most important consideration in system design
“It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas”, Brooks comments, “[the] ratio of function to conceptual complexity is the ultimate test of system design”. This definition is great because it describes what distinguishes good code from bad. It also helps in clarifying the objective of certain processes we have at the office, like code reviews and pair programming. By collaborating and reviewing each other’s code, we can hold each other up to high standards and maintain conceptual integrity.
An interesting example they brought up of conceptual integrity was the WIMP (windows, icons, menus, and pointing) interface of the modern GUI. I never much thought about it until now, but on further inspection, it is incredible how much can be done on a modern OS with such a simple concept (compared to typing commands in a terminal, as was computing before the GUI).
Documentation is an essential tool that can be the difference between catastrophe and success
A couple of months ago we started instituting a process where features are planned out using spec documents. It was a process modeled after what we were already doing informally: putting together a rough outline of how we were going to build things out so that we could get feedback on it. Over time, we’ve seen these documents come in handy, but only if the document has an owner, and only if effort is put into it to make it the canonical source of truth for anything related to the feature. This requires careful effort in not just making sure the spec covers all the details, but also in writing it such that it is easy to digest. I think the ability to write organized prose is undervalued among technical people, as this is essential in making sure a spec document delivers value.
People don’t set targets or write specs if they feel the organization will not see them as tentative.
I liked this note because it makes sure we understand that specs are living documents and never to expect them not to change over time.
Members of the team need to strive to be flexible because change is the only thing that’s guaranteed.
“Structuring an organization for change is much harder than designing a system for change. Each man must be assigned to jobs that broaden him, so that the whole force is technically flexible. On a large project the manager needs to keep two or three top programmers as a technical cavalry that can gallop to the rescue wherever the battle is thickest.”
I truly believe that the last sentence applies to each member of the current engineering team and our aspiration is to make sure every member can be part of the “cavalry”. It helps define who we are looking for technically as well, since we expect every member of the team to respond fast to changes in requirements, fast in both communication, understanding, and implementation.
Program maintenance is 40% more than cost of development
Cumulatively, I’ve spent a few months out of this year working purely on regressions and bug fixes. We need to always remember that maintenance is far larger than development. It is especially important as we build out features and make choices about technical debt and how much effort we’re going to spend time on testing. Because a couple days spent on testing can save us weeks of time fixing bugs. And it results in happier customers!
Bugs will naturally scale with time and customers
The more time customers spend with a product, the more bugs they’ll find as they bump into edge cases. I’ve experienced this firsthand as well.
Tooling - make effort to share and find tools. Unified toolsets can boost productivity.
We definitely embody this both on the engineering and customer happiness teams at our company. Although, as we’ve grown it’s become more difficult to get tool usage to be adopted company-wide. Finding and adopting great tools is something our company culture promotes.
Disastrous schedule slippage happens one day at a time.
The takeaway for this point is that it is essential to recognize slippage faster and communicate it clearly. One thing that I have found works is setting more granular targets that allow for more segmented estimation. Targets that are 1-2 weeks are less likely to be totally derailed than targets that span multiple months.
Milestones need to be concrete and defined with ‘knife edge’ sharpness. On the flip side, fuzzy milestones are actually millstones that grind down morale
I have seen this first hand, but wasn’t able to pinpoint exactly what was causing the problem. I am glad to see the idea expressed in a way that presents the root of the problem clearly. Milestones need to be concrete. This is where having a test suite comes in handy, because tests either run green, or they don’t.
No silver bullet, software is inherently complex and no management or process changes can improve the inherent complexity.
Closest thing to silver bullet is to buy not build
We’ve been lucky to have the budget to buy and not build, and personally my preference swings towards buying instead of building for components just because maintaining your own system is expensive! I found it fascinating to hear someone from 40 years ago, before the existence of SAAS, say the same thing.
In conclusion, I think the book had a plethora of wisdom, a good amount of truisms, but allowed me to better form a framework that our existing engineering processes can call on for justification. For example, pair programming doesn’t just make our code vaguely better, it establishes a consistent conceptual integrity. Why do we set concrete targets for ourselves? Because disastrous schedule slippage happens one day at a time. And how about removing that feature from Tint 2.0? Because of the Second System Effect! The reason why this book is timeless is because it’s about people, not software, and as long as writing software is complex, people, not computers, will be the ones dealing with the complexity.
October 3, 2014
I’ll be the first to admit my failures. But I hope that also means that I’ll be the first to learn from them. Over the past year, I helped write a backbone app that started out as a free widget to powering a display in Times Square. The rapid growth in customers and increasing demand for key new features helped accelerate an already growing amount of technical debt. As we tacked on new feature after new feature, things got complicated. Eventually, we reached a point where we all agreed that a refactor was in order.
We chose to refactor using Marionette because we were already familiar with Backbone’s patterns and figured that it would be an easier learning curve. Sure enough, after 3 weeks using Marionette to refactor Tint Analytics, we’ve gotten up to speed. We have identified some key Backbone mistakes we made that Marionette helps us handle. Here’s a list of Backbone pitfalls and how Marionette works to help us avoid them.
Views containing too much logic
In Backbone, there are only 2 kinds of objects: Models and Views. Models help connect to the API and serve to maintain state. Views do everything else. As you can imagine, this can lead to Views which start out small, but quickly grow. And since the library doesn’t have any established pattern on how to handle composition, it’s easy to have Views grow to an unmanageable size. Marionette helps us by extracting Views into Controllers and Views, and encouraging highly composited architecture with the idea of Layouts and Regions. The Marionette Controller is in charge of view initialization and communication between subviews, acting as a Mediator.
Not having enough Modularization
This point also ties in with the above point of views containing too much logic. Because it requires a lot of boilerplate in Backbone to create composite views, it is too easy to hold off on creating lots of small views composed to create the larger overall view. Marionette helps by extending Backbone Views into ItemViews, CompositeViews, and LayoutViews. Marionette automatically takes care of accepting collections and iterating through models to create ItemViews, reducing the cost of composition and increasing modularization of view code.
Forgetting to unbind events causing unexpected behavior and memory leaks
Backbone has no pattern or tool to help get rid of zombie views. Instead, it relies on developers to come up with their own solutions to unbind events. I relied on the BaseView technique to make sure events were being unbound, but I always thought it was a little goofy for the library to not handle this automatically. Luckily, Marionette does. Marionette Controllers, Views, and Modules have built in functionality to automatically unbind events. Yay!
Interdependency through global variables
One conundrum that I encountered while building our large Backbone app was how to handle multiple views that share a model, or a view that needs to reference another view’s model. I eventually ended up having a couple global state variables. The problem was, there was no way to figure out the parts of the code that were manipulating or reading the global. In addition, it was easy for the Backbone model and the global variable to become out of sync. Oy!
Entities to the rescue. Marionette Entities are an additional abstraction that allows you to have clearly defined entry and exit points for your models, making them all both globally accessible and also well defined and easily debuggable. It also lets you easily implement functionality like making a model getter a Singleton or having custom model initialization. The best thing is that the View considers the Entity a black box and communicates to it via messaging, reducing unnecessary coupling.
A giant router with all module initialization
Almost every sample app I’ve looked at for Backbone has a single router file. For simple applications, this works fine, but for larger scale application, the router can grow to be unmanageable. A large router is hard to read and maintain because it often times will be responsible for initializing unrelated Views and Models. Marionette helps solve this by distributing routing and initialization among marionette controllers. It allows you to define Model and View instantiation where you can find it later.
Overall, the codebase is looking easier to digest, although we still have much to learn. By not making the same mistakes we did above, you too will be able to avoid code hell, and instead, see something like this:
August 14, 2014
An open letter to the tech workers of san francisco
Dear fellow tech workers,
“We interviewed a senior being evicted from their home in the Mission who said, ‘Google is Hitler’. What would you say to that?”
An interviewer from TechCrunch asked me this question a month ago. The question didn’t surprise me, even though it should have. It seems like that’s all that’s been in the news lately.
The same week, I went to a Youth Speaks poetry slam with Monica. This was the first poetry slam that I’ve ever been to, and I was excited to hear youth speaking out about the issues they hold dearest. The event was fantastic and it inspired me to see youth cultivating their creativity.
But it wasn’t long until a slam came up accusing “toxic” tech workers of ruining the city:
Link to video
On valencia now that's all you see. It's spreading. Like an airborne toxicity. And that's exactly what I mean, it's a toxic city. So they force us out. Both young and old. Raised up the cost of living, no rent control. So if we can't afford to live our only option is to die or move out to Tracy or Antioch like a couple of my guys. While I'm in my city, they're out in the burbs. Not to mention that Twitter and Google are too strung up for words. They're speechless. Denying the fact that the only ones who can afford to live here now are the ones that are Google bussed in. Like they're employees from the mystical wonderland called the valley of silicon. It's really damn sickening, and I'm a 19 year old mother f**cking San Franciscan, damn. - Jerome Robles-Reyes "In My City"
It seems, from all fronts, that the city hates tech workers. Even SF Streetsblog, a blog I hold near and dear as a daily cyclist, declares the tech community as a monoculture that “blames those less wealthy for their own problems”.
Monocultures serve no one, including those whose culture takes over. - Fran Taylor [SF Streetsblog](http://bit.ly/1Ad0qEo)
From these articles, I should be ashamed. I should move back to where I came from. I guess that would be Indiana.
But I’m staying in San Francisco. The solution to evictions is building more housing. But building more housing isn’t going to conquer the root problem which is the animosity many native SF’ers have against people who work in software.
Instead of leaving, I’m going to see all the hate as a challenge to become a better member of the local San Francisco community. I think as tech workers we can make a big difference in public perception with consistent, everyday steps that any techie is capable of doing. You don’t need to be a community organizer to make things happen. A community is just a bunch of ordinary folks having relationships with each other.
I did some research, and apparently there are 20 ways to not be a gentrifier as described by local paper Oakland Local. It inspired me to make a list of my own:
Go get a haircut at a local barbershop or hairdresser (price must be < $15 (guys) or < $30 (gals)). Talk to your hairdresser. Talk about the car accident that happened down the block last weekend. Talk about the traffic issues from Outside Lands. And listen. Learn what’s on the mind of folks in the community.
Read and talk about local news. Be aware of the pulse of the city and about what’s affecting everyone, not just the software industry.
Get involved in local volunteerism. - This summer I helped Doug, a local SFUSD high school teacher, in an externship hosted at Tint. He learned technical skills with us that he can bring to the classroom in the upcoming school year. This fall, I hope to mentor local high school students so they too can learn how to write code. There are lots of resources for you out there, you just have to look! For starters, check out SF Citi or Mission Bit.
Participate in local art. It could be as simple as going to a poetry slam or an art walk, or go even further! My friend and colleague Brandon is a great example for this. He’s working with a local organization called Clittorati on the Vulvatron. What could be more SF than a visually iconic mobile art piece, empowering women, goddesses, and the feminine identity?
Don’t talk down to people less fortunate than you - I once met a fellow tech worker who condescendingly referred to the 38 as the ‘dirty eight’. As someone who rides the 38 every day, it made my blood boil to hear that comment. I finally knew how it felt to hate techie outsiders. Don’t reinforce negative stereotypes.
These are just a small subset of the many things that can be done to cultivate a community and dismantle the image of the evil techie outsider. But, the biggest change that anyone can make is to treat everyone from all walks of life with respect. Even with the fairest of intentions, it’s easy to seem condescending to outsiders, so it’s our responsibility to think and act actively to participate in the community.