For the purpose of this illustration, when we talk about the viewpoint of the CEO and the CTO, it’s to make it easier to understand that we are basically speaking about the sales/business side and the programming/development side. The idea vs the architecture. For brevity, even if one of these early team members doesn’t have a C stuck to their title, let’s just call them CEO and CTO.
Share Your Why
One of the biggest sources for miscommunication between the CEO and the CTO is a failure to understand why. Why does the founder want this code written on that platform, when he doesn’t even write in that language? Why can’t the developer get this simple feature built in less than a week? The funny thing about respect is that you’ve got to show a little humility. Humble yourself and ask the question. Show courtesy and answer the question. Transparency shows that you have respect for your teammates. “I am in early talks with a potential acquirer of this product, and if we build it on the same platform that they have, I think the partnership has a better chance of succeeding.” Hire someone who can be trusted with this information. It shouldn’t be a secret. “That simple feature actually requires a restructuring of the architecture that we originally set up to talk to a different server. Here are the steps involved in making that change.” You must be willing to educate your teammates on the proper care and feeding of yourself. Explain what motivates you, how you can be best productive, and when the best time for a “shoulder-tap” will be.
Value Team Work Styles
People are motivated by different things. Treating the team to a celebratory lunch or a trip to the driving range might seem like the best reward, but if it doesn’t actually speak to each team member, respect that you should learn their language to provide proper accolades. On the same token, don’t decide that 8-5 in a communal workspace is the way that every member of your team will get their best work done. “When you interrupt a programmer just to bounce a simple idea off of me, you’ve potentially sunk four hours of work down the drain. If we need to talk about something, be clear up front about the type of conversation we are about to have,” said Jeremy Woertink, a developer who was willing to share the ups and downs of life at one of his early companies. On the other hand, Gabe Shepherd, who was running the company, didn’t always need to know the technical ins and outs. “Either be quick, or tell me everything,” he says. “Sometimes, I just need to know one simple thing: where’s the bottleneck?” Shepherd says that learning to set expectations – which differed with each team member – about the level of detail he needed helped to improve communication and respect between those with the idea and those who were building it. Woertink illustrated the Programmer’s Arc: If you want me in the office to shoot the shit and be available for team activities like random ping-pong at 2 pm, my work will get done at a much slower pace. He explained that it took a long time to get the rest of the team to understand this.
Shepherd notes that understanding this really helped him improve communication with this team and other startup teams that he’s helped to grow. “At first I thought it must be an excuse,” he said. “If I can get right back to work after a welcome distraction, why can’t he?” Once he realized that a programmer needs a ramp-up period to get into a block of code, he was able to show more respect to the needs of his teammates. Just as it’s important to understand the “language” that your spouse, significant other, and family members speak, learn to understand the needs of your team so that everyone can feel the communal respect that produces the best results. Header image credit: https://www.flickr.com/photos/thebigdurian/
