We chose technology as our career, and technology, with all its beauty, is complicated, messy, and changes with neck-breaking speed. We have hectic lives.
Many of us deal with this constant change by compartmentalizing our time and reducing number of interruptions to our workflows. This works extremely well, to a point.
As Engineers and Product Managers, we are passionate about products we are building. We want them to be useful, beautiful, fast and technologically sound. In broad strokes, engineers trust PMs to lead “useful and beautiful” efforts, while PMs trust engineers to take care of “fast and technologically sound” bits. And as we know, quality of this partnership can make or break any product, and single most assured way to ruin a product is to introduce chaos into this arrangement.
Chaos is not the same thing as change, changing requirements, or occasional fire fights with systems being down. Change is OK. Change is good. There are well-known methodologies that allow us to deal with change.
Chaos is something different – it is activity that does not contribute to product goals. Some of it comes from not having clearly defined goals in the first place, and some of it comes from not having enough constraints, allowing us to lose focus and waste time on things that aren’t important. Trying to second-guess others and work around them is contributing to chaos. Not relying on data for insights is chaos. Scope creep and feature favoritism is chaos. Untidy task management practices are chaos. Breaking build all the time is chaos. Not looking at bugs every morning and missing a critical one is chaos. And chaos is poison.
As technologists, we can’t help it – we constantly think about how to make our products better. Even outside of the office. Even as we sleep. Engineers think about their code, PMs think of new ways to make users’ lives better. We think of a right time to bring back something that was discarded a while ago into “not the right time” bucket. We look at data and have heated discussions about what it represents and how to move forward. We argue about design and other things. That’s how we build beautiful, inspiring products that people love to use. But this is only possible when fundamentals are solid and we don’t have to constantly worry about small things or take care of constant “Sky is falling, let’s get moving” situations.
We still deal with small, everyday problems that come up from time to time, this is unavoidable. However, when they are relentless and omnipresent with increasing volume, they begin to occupy our mind, and forward progress on the project is lost: death by thousand cuts. All because of chaos.
So, how can we deal with this problem? By introducing culture of autonomy and building cohesive teams that like working with each other. We need to hire best people and let them work their magic, welcome and give honest feedback, don’t hesitate to ask for help, and above all, trust our team mates to have our back. Here are some good things that I’ve seen and practiced in many places, and things we live by at Wetpaint:
- Our PMs take time to look at the data and say “no” to their understandable desires to cram as many features as possible into the product.
- Our PMs don’t dictate how to implement features, but they are technically savvy and of course have an opinion. So they ask engineers to educate them about why certain things are implemented this way and what were the alternatives.
- Our engineers watch builds like hawks and everybody obsesses about automation, unit tests and code coverage.
- Our Test Team can openly ask others to help verify and close down open tasks as soon as sprint begins. Our Dev and PM team members gladly volunteer their time to help out. When Test Team feels that our new features lack quality, they speak up and we, slightly embarrassed, fix things.
- Our technical team can openly request for a feature to be cut from current sprint because interruptions came in or other features were under-estimated. PMs are happy to discuss alternatives and move things around. In return, Dev team becomes accountable for screw-ups with estimates.
- Our prior decisions are reevaluated and bad ideas are killed in cold blood given new evidence in the form of data.
Our single most precious gift to our project partners is shielding them from chaos and letting them think. And work. We bet our careers on each other, so we need to help make each other successful. And we don’t have much hope for an emergence effect to arise from chaos, because our team is not an ant colony.
Recently I’ve started interacting with some people in Seattle startup community. Honestly, I half expected to find a bunch of antisocial geeks who troll about their employers and exchange “check out my new killer social entertainment network” messages. To my amazement, I found a really vibrant community of smart individuals who are willingly helping each other with useful information, references, ideas, and treat each other (mostly) with enormous respect. These people have nothing to gain from giving out their advise or sharing their valuable ideas. On the contrary, somebody somewhere might benefit from this information to make their endeavor more successful, to get better funding, to hire better engineer, to meet interesting people.
So I started thinking about why this happens in this age of cutthroat competition. I don’t think it is Karma or “Pay it Forward“, though for some people out there that is a legitimate and commendable driver for this behavior. Instead, I think that it is a basic drive to look for and find better social interaction in our professional lives. Plus a lot of networking, of course. I firmly believe based on my own experiences that we strive to be accepted professionally, and these loosely coupled peer-to-peer communities satisfy that need. People treat each other as equals, assume the best instead of the worst, listen, share their advice and help because they like to do it. It gives them a great feeling of self-worth, especially when they get the same kind of treatment from the others. Notice that this is slightly (and in some cases drastically) different from the corporate world. First, no matter how senior your position is within your company, you are constrained by its reporting structure and by its culture. In some situations you are treated as a resource, and in some situations your opinion or ideas have hard time reaching the right audience. In these startup communities, however, things are different because these constraints don’t exist. So meeting somebody for coffee and chatting with them about your and their ideas is a much simpler proposition.
So, in light of these observations I’ve made a resolution this year – to help my friends in their crazy ideas when they need my help, or advise, or a sounding board, or all three. Just to have a professional environment outside of work that is slightly different from what I have at work. Just to geek out with my buddies on my free time while feeling important. Just to be free for a few hours every week. Ha!
Remember the Triple Constraint of Project Management? Remember how horrible and out of sorts it feels when your management attempts to maximize all three sides of the triangle?
Well, I am going to attempt to make an analogy between Project Management constraints and your Happiness at Work constraints. When I say “happiness at work”, I mean a situation when you are mostly happy to go to work every morning. I don’t have any illusions that things could be perfect, at least not when you’ve been working in your current role for some time. I realize that there are always going to be problems, but those problems shouldn’t give you heartburn every second of every day to make you leave – those are the problems you or somebody else on your team is methodically working to solve and the rest of you are either helping or at least not standing in the way.
So what’s the constraints? During my time in software development, I found that my personal happiness at work rests on three main constraints that are at the base of my professional Maslow’s Pyramid:
- Product I am building
- Team I am working with
- Technology I am using
When all three are balanced (once again, they can’t be all perfect all the time) – I am happy. When one is persistently screwed up, I am beginning to worry. When two are out of sorts, I am headed for the exit, unless I see a way to fix the problem. Let me explain why.
Product I am building gives me and everyone around me purpose. Multiple factors contribute to good or bad feelings about the product. I like when I believe in the product, when I think it solves a real problem, when I find the problem space fascinating, when I feel connected to my users (this could be just an illusion, right?). Take this all away, and suddenly there is no purpose, no goal, no mountain to climb. It could be OK for a short while, but it gets on my nerves very quickly.
Team I work with defines my social environment at work. I like to work in a team based on mutual respect, accountability, driven by results and not too political, and who doesn’t? I also tend to pay attention to processes that exist in a team. How do ideas get communicated up the chain? Are they dismissed out of hand, do you have to be a member of “in” crowd to be heard? Is your management effective, accessible and open or are they just along for the ride? Do they listen to valid concerns and take action to make the team better? Do they defend the team or just themselves in battles that are worth fighting? Basically, I try to evaluate my team using one main criteria: can we conquer team dysfunction or not?
Technology I deal with on a daily basis is hugely important for me as well. Basically, I want to be able to answer “yes” when somebody asks me question #9 on the Joel Test. I have to spend my working days making technology do what I want, so it is only reasonable that I should be a pretty demanding customer. I don’t want the technology to waste my time – I want it to help me. I also want to enjoy working with it. I also want it to be marketable enough for me to learn. No matter how enjoyable and effective Smalltalk is, the reality check tells me that becoming a Smalltalk expert is probably not as good for my resume as knowing Java or C#. And this is coming from a person that loves Smalltalk. Same goes for internal tools that most companies have. None of these tools are marketable (they are internal), so if they are clunky, old and hard to work with, I will hate them.
So what do I tend to do when any of these pillars becomes jeopardized? Well, it’s always the same two choices when it comes to your basic needs being threatened: fight or flight, except I alway fight first. I stay loyal, I try to influence non-technical decisions about the product, I try to lend my time, expertise and advise to fix my dysfunctional team or I try to push for technological choices that I consider more promising, applicable and marketable.
However, if I can’t convince myself that at least two out of three are acceptable to me, there is nothing I can do to make them acceptable and the situation isn’t getting better, I think that it’s time to move on. As loyal as I am, there is always another team, another project, another challenge.
Because life is too short to spend it in a dead-end job you hate.