by Aunim Hossain
Baller. You’ve spent months running around, talking to everyone you know (or don’t know), attending conferences, scouring the online job resources…all with the goal of building your dream team that will take this from a great idea to a company that will change the world. And you rocked it. You have the team you need: one product manager (you), three developers with front-end and back-end skills, and one artist/UI guru.
You feel like you’ve arrived. You say to yourself, “now, it’s all about getting it done, but that should be pretty simple with the team of ninjas I assembled, right?” But this is where many promising founders stumble. Even with the right team in place, success is not guaranteed. While there are many variables that determine success, one of the most important variables that founders can control (and often don’t) is building the right culture.
Culture is created through the processes that founders and the team members put in place to complete tasks. As those tasks are completed, the team figures out which processes work and which should be revised. When a particular process becomes second nature for the team to complete a certain task, it has effectively become culture. As founders, it is our job to guide the creation of the best processes and make sure that the processes that become culture are the right ones for the team.
In this post, I hope to start a list of the best processes that have come to define the culture of our team. In this first try, I’ll talk about our experiences with communication and time management.
So tell me what you want, what you really really want…
Oh those Spice Girls were sages. And it makes sense that they knew what they were talking about when it comes to communication: they were a startup had to manage a team of five divas. In our startup, with my own team of seven divas, we thought that putting everyone in a room together would ensure strong levels of communication. But several major problems from spec misunderstandings, to code deployment issues, to artist delays continued to creep into our work hours. In the end, we figured out that the fundamental issue was a lack of communication. Although we’re still working a lot of these issues out, here are a few processes that we’ve put in place that will hopefully create a culture of over-communication within our team:Create a Backlog of Detailed Specs: As the product person, my ultimate goal is to take the idea that is trapped in my head and make it real. But because I need help from other people to make this happen, my first task is to take the idea that is in my head and put it in the heads of everyone on the team. Now before we figure out how to really do mind-melds, we have to rely on specs. So make your specs as detailed as possible. Don’t assume that your team will fill in the details, because where there is uncertainty, there is room for miscommunication. Also, if there is a feature that is important in the future, don’t wait to write the spec. It is critical to build a long backlog of specs so that the team knows where the product is going and they can build functionality to be flexible and accommodate what’s coming next.
Daily Scrums: Although we started this practice on our first day and most teams use this process, I know that it has been instrumental to our team’s cohesiveness. Functionally, a Scrum for us is a daily team meeting that lasts only 30 minutes (everyone is standing up so that it’s clear that the meeting will be short). One by one, each person has the floor and talks about what they worked on yesterday, what they are working on today, and any questions that they have for other people. After setting it up, our team started using it for functions that I had not thought about before I saw it happening. For example, we use it as our daily deliverable when I am able to see where we are at on the code and art. Other team members use it as a way to make sure they are on the right track when solving a problem. Other team members use it as a way to look at the big picture of what we’re doing and get pumped up about our progress.
Other Practices: We set up skype chat for each of the team members so that communication lasts all day. Often, there is a tremendous amount of collaboration that happens in a seemingly silent office. We also set up a wiki that documents, in a central place, the components of each of our Sprints, and what everyone is responsible for. It is a constantly evolving document that is primarily updated by me, but it is very helpful in understanding what people are working on in the long term and where there may be gaps.
In the end, as we set up all of these processes, the most important lesson that I have learned is that great communication starts at the top. Unless you demonstrate that you are communicating yourself, your team members will likely not communicate either. For example, if you say that everyone on the team should email whenever they have questions, it will probably take several emails from you before the team buys in and takes it from there.
Time is on my side, yes it is…
In this section, we learn from the Rolling Stones. It’s an ageless, optimistic message that runs in contrast to the typical entrepreneur’s mindset, that stresses impatience (and the cornerstone of lean methodology). Now, I definitely agree with this mindset: we can’t just sit on our ideas while someone is out there hustling with a similar one; we can’t just keep working on prototypes without getting them out to users who can teach us; we can’t go back and spend days cleaning up code when there is so much to be done with our existing code base. I agree with all of that. What I don’t agree with, however, is the mentality that time is the enemy. As a founder, it is important to frame time as our friend.
This is an important lesson for me because I was always under the impression that, by setting stretch deadlines, I could get more out of me and more out of the team. By framing our work as a race against time, we could encourage hard work and higher performance. However, this view has only served to make us look at the short-term goals and lose track of the long-term needs of the company. With time as the enemy, we introduced all-nighters, hardcoding, a lack of flexibility, low morale, and stress into our processes. By doing so, we ended up being more behind in reaching our goals. Thus, these processes below ensure that we all look at time as our friend in product development:
Balance Speed vs. Scalability of the Code: When your team is “costing out” features (determining how much development time, cost, and art is needed for a feature), it is important to tease out the real tradeoffs between getting done on time and the corners that will need to be cut. For the product person, it makes sense to include the entire wish list in the spec, but you should be aware of what tasks are vital and which can be pushed. As an engineer, it is vital that you understand which shortcuts can be used now to meet this deadline, and which shortcuts don’t make sense because it’ll take more time to revisit three deadlines down the line. It’s very hard for everyone to understand these tradeoffs, especially early on in the development cycle.
Therefore, I believe that it is important to set easy deadlines with several days of cushion for the first few sprints. This will give the team the flexibility to focus on building scalable code early and establish understandings of the tradeoffs that they will have to make later. Technical debt is inevitable, but it should be avoided early because it compounds. As the team learns more about how they work together and about where the product is going, the deadlines can become tighter. But early on, focus on the scalability vs. speed.
Establish Best Practices…before you need them: When you believe that time is on your side, you can spend some time thinking about what processes you will likely need in the future and build to them now. By doing so, the team can learn how to use them before they are really in a jam. On our team, we set up bug tracking through Bugzilla, subversion hosting and deployment through Beanstalk, and other systems before we had bugs and multiple developers in the code. By doing so, we were able to create a plan for scaling so that when we hired people, they could get ramped up quickly. Indeed, if you can take the time to look ahead and plan for the future, you can save a lot of time today.
Now, there are only a few lessons that I have learned as we tried to create a culture through the prototype development process. In your comments, please feel free to comment on these processes, but also feel free add your own best practices. I’m looking forward to reading them.
