A lifetime ago in a galaxy far, far away my cofounder Michael came to me and gave me an intervention. We had a problem, he said, employees were unhappy. People were getting burned out and there was an 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 realized 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 were doing. We had created the startup equivalent of Lord of the Flies, complete with new employees getting thrown into a foreign environment they are completely unequipped to survive in and 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 to jump in without warning when things weren't following unsaid directions. Anyone who has experienced this before knows that it is liable to make you a bit twitchy.
In the next month, Kevin, our COO, talked to everyone in the company and gathered feedback that might not have been directly shared with a founder. Here's the typical project workflow, version 1:
- 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, 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 learned 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 fuck up:
Empowerment doesn't mean letting everyone do whatever the fuck they want
If you listen to words and not the meaning, a lot of startup talk seems to say that you should just 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. Creative 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 just say yes whenever someone suggested something, but then let it die later through neglect, 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, let employee figure out the solution
At the end of the day, smart people mostly aren't motivated by money or titles in the long term. 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: mastery, self-direction, and purpose. In a product engineering organization, those things fit together if you provide employees with an area they can be an expert and make local decisions in, but that also fits into a larger purpose or problem. Many of the problems that we've experienced stemmed were 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 fit 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 lead to inconsistency and paralyzed the engineering process. At the end of the day, 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 founded 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. You've probably also been making most of the decisions yourself up until this point. 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 color 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.
Instead, 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 not just to talk 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 get understand why he was working a project, and which aspects of a 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. Turns out it was because we weren't explaining what we wanted to do. When we started doing so, it turns out most of our best ideas started coming from people who weren't the founders.
A more general version of letting your motivations be known is just generally communicating 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 favorite 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 whom 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 specialization: management bandwidth is a product, even though it might not feel like it.
I am clearly not a management savant. I like to think that I'm good with people, but I know I'm not amazing. I don't particularly love management, except as an instrumental tool to creating a cohesive, productive team that makes great products. Doing many of the things I've listed above, particularly remembering to do them consistently, has been difficult for me to adapt to. Often, I would forget what management tasks I was supposed to do and focus instead on something I shouldn't have been doing. In order to make sure to do things consistently, I found myself following the advice that I should create a checklist of things to do ("Is anyone blocked on anything?", "Do any meetings need to be scheduled?", etc); one for the beginning and one for the end of the day, and follow it religiously. It is still on some days a struggle.
Writing this essay has been cathartic, because it is the truth. I owe a great debt of thanks to Chintan, 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 realizations 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.