A lifetime ago – long before we launched Socialcam – my cofounder, Michael Seibel, came to me and gave me an intervention. “We have a problem,” he said. “Employees are unhappy.”
People were getting burned out and there was a dangerously increasing rate of attrition. “What do you want from me?” I replied exasperated as our conversation became heated. But he didn’t have any answer, outside of seeing the symptoms of something deeply wrong.
As our most important conversations typically go, I eventually got over my wounded ego and realised that he had a key insight here. The things he mentioned were serious and indicative of a lack of leadership that was caused as much by the things we weren’t doing as they were by the things we were doing.
We had created the startup equivalent of Lord of the Flies. New employees were getting thrown into a foreign environment that they were completely unequipped to survive in, then getting bashed in the head with a rock. We the founders had operated the company with little direct management for years, under the pretense that we were empowering employees by letting them work on things they wanted to do. In reality, we were often stepping back just enough to been seen out of the eye’s periphery, often jumping back in without warning when things weren’t following unsaid directions….
In the next month, Kevin Lin, our COO, talked to everyone in the company and gathered feedback. He found that this was the typical project workflow:
- Vague problem definition: “Create an automated test suite for the website.”
- Employee defines it in some way that we didn’t actually have in mind: “Create an extensible, Selenium based framework for performing every action a user can on the site.”
- Employee works on that for a while, sometimes months, without feedback: “I’m making great progress!”
- Manager checks on progress, has a “wtf” moment: “Wait, I just wanted something that pinged five URLs and checked for 500s.”
- Massive micromanagement ensues: “OK, clearly you don’t understand what we’re doing; I’m going to have to take over.”
- Massive employee disenchantment: “WTF just happened?”
With a lot of help from our new VP of Engineering, Chintan Shah, we created a plan for addressing our most egregious issues. Many of the lessons we learned could probably have been prevented had we picked up a management or communication book or two. But as always, the lessons you hold dearest to heart are the ones you’ve taught yourself the hard way.
Signs you might have a problem, and that the problem might be you:
- Employees burn out after months. Team members work increasingly less on average as they spend more time at the company.
- Lots of people seem to be implementing projects in ways that you didn’t want, or that don’t meet the goals you had in mind.
- You feel like people aren’t getting anything done, even though you employ lots of people, all of whom are smarter than you and just as hard working.
How to not f*ck up:
Empowerment does not mean letting everyone do whatever they want.
A lot of startup talk seems to say that you should simply get a lot of smart people together and let them do whatever they want until something sticks, and that is a recipe for success in everything (product, team happiness). This is wrong. So wrong.
Creativity comes from constraints and direction. For us, the hard part of this was to actually define the problems / goals we were attacking and then ruthlessly refuse projects that didn’t address these. Instead, we found it so much easier to simply say “yes” whenever someone suggested something, but then let it die later through neglect or lack of interest – on purpose, or otherwise. This is a horrible idea, because it not only communicates an utter lack of focus but it is completely and utterly opposite of honest communication, and leads to people feeling betrayed, and rightly so.
Instead, you should provide a problem and framework, then let employee X figure out the solution. At the end of the day, smart people mostly aren’t motivated by money or titles. Motivators like those are like buying new possessions; after the newness wears off, so does the appeal. Daniel Pink does a great job outlining what motivates people in this video: Self-Direction, Mastery & the Purpose Motive.
In a product engineering organisation, those things fit together if you provide employees with an area in which they can be an expert and make local decisions in, but that also fits into a larger purpose or problem.
Many of our problems existed because we sacrificed one at the expense of others; for example, allowing people to pick projects (self-direction) that didn’t fit into our company goals (purpose).
People want to have input. Cheer up, this is a good thing; it means they actually give a shit.
But how do you reconcile the fact that smart knowledge workers want to have self-direction, but ultimately you have to say no to things that don’t address the company goals? Bewilderingly enough to the average entrepreneur, it turns out that people are ok with “no.” Most smart members of a team want to have input, but don’t need to make every decision themselves. For us, having regular brainstorming sessions where everyone could generate ideas for a product in a given area was a good pressure valve for contributions; those ideas were then taken and curated by our product managers into a cohesive product.
Having a hierarchy isn’t a bad thing. Having no idea who has the final say is a bad thing.
Because you need to stay on target and only do projects that address your goals, it is important that there be a limited number of people who are responsible for setting those goals and are responsible for certain decisions. This was a hard thing for us to grasp; in the early days of the company, we made decisions based on consensus (translation: through massive intracompany arguments). Team members didn’t know who was responsible for various product decisions, and often times this led to inconsistency, paralyzing the engineering process. The egalitarian spirit in us had trouble saying “Person X is in charge of product decisions, Person Y is who you should tell if you need to take time off.” But, in the end, it saves a lot of mental processing for everyone once you add these types of rules, and ultimately decisions get made in a much more fair and transparent way.
Don’t micromanage. You’re probably not nearly as smart as you think.
If you create a company that’s big enough to have management problems, you probably think you’re a full-on genius by now. Yes, to the public you might appear humble (I might as well!), but your college buddies are probably pushing paper and ticking off days to retirement while you started something that is surviving based on your sheer effort and wits alone. Thus, while you’ve heard you shouldn’t do it, micromanaging the team is probably tempting.
But don’t do that. In your heart, you know it is wrong. You hired smart, creative people who don’t want to just colour by numbers. For me, when I objectively looked back at details I had micromanaged months later it was pretty clear I hadn’t been making anything better. Instead, get rid of people you don’t trust enough not to micromanage. If you look around and that’s everyone, then the problem is probably with your control issues.
Provide regular and expected points where others (management, peers, etc) get to have input / oversight, and DON’T SKIP THEM. At the same time you are stepping back from micromanaging, you can make sure you get an opportunity for oversight by making it part of the process to have check-ins where you (or others) get to give input. For Justin.tv, this meant scheduling regular spec / architecture reviews before beginning projects and code reviews at natural milestones. It is critically important that these be consistent: consistency manages employee expectations and makes your process not arbitrary.
Meet regularly, and not just about code.
Since I’d never worked at a real job before starting a startup, I didn’t understand the purpose of basic management processes. I thought meeting regularly with employees 1-on-1 without a purpose grounded in a decision that must be made was a massive waste of time. It’s not.
Meeting regularly just to discuss how things are going, what team members feel like they are getting out of the job, feel out potential issues, and gather feedback can give you a chance to discover brewing issues before they become massive problems. Also, it gives people the opportunity to share their ideas and feedback in a consistent environment, and let them know you care about hearing their ideas.
Let the team know your motivations.
An employee who joined the team two years into the company’s history doesn’t have the same motivations as the founders. Team members who are implementing one part of a strategic vision don’t necessarily see the whole picture (not because they couldn’t, but probably because their jobs might not afford them all the information and time needed to consider it).
One simple jewel of advice given to me by one of our senior software engineers, Joseph, was that if we shared our motivations as decision makers (e.g. “We’re working on this project to generate revenue in the short term, instead of infrastructure improvements because we’re trying to hit a short term revenue goal
of X”) it helped him understand why he was working on a project, and which aspects of that project to spend time thinking about improving. In previous eras, we had asked ourselves why employees weren’t coming up with ideas that were in line with things we wanted to do. It turns out it was because we weren’t explaining what we wanted to do. When we started doing so, our best ideas started coming from people who weren’t the founders.
A more general version of letting your motivations be known is to communicate assertively. When I first started managing people I was not explicit about expectations or deadlines. This was because I was scared about imposing my demands on others.
Unfortunately, this leads to you being upset because things you took for granted (product questions, timelines, etc.) weren’t actually explicitly communicated and thus weren’t followed. You can change this pattern by taking the time to communicate effectively. This is one of my favourite books on the subject of communication.
Your job as a manager is to provide leverage for other team members, not do work yourself.
For me, there is a massive temptation to program things myself. I like programming. But once you become a manager you must resist this temptation. There are people that I manage who can get programming tasks done 10x as quickly as I can. Efficient allocation of resources dictates that I should not be programming; if I can provide 10% more productivity by boosting said programmers output (say, by removing communication, blocking time, or better defining a spec) then I have already made back 100% of my time if I were to spend it programming myself. If I do this for everyone on the team, we are all better off than had I just been programming.
This is the comparative advantage that comes with specialisation: management bandwidth is a product, even though it might not feel like it.
Writing this essay has been cathartic, because it is the truth. I owe a great debt of thanks to Chintan Shah, who had the unpleasant job of dragging me kicking and screaming through the coals to becoming a decent team leader, which I resisted the entire way; my cofounders, who supported the plans we came up with and had faith I could figure some of these things out; and most importantly the employees who had to put up with our extremely poor management prior to many of the realisations we had as the company’s leaders, pretty much all of whom forgave our faults.
Without all of these people, I wouldn’t have made progress becoming a better team leader. But vastly more importantly, without them I wouldn’t have grown into the person I want to be.