This morning I read a post on Twitter that got me thinking about team and the importance of ethos.

I’m a firm believer that all working teams need guiding principles to operate by. This is especially important for engineering teams, which work extremely long hours and tend to be at the end of the proverbial product “whip”. How your engineering team operates, in the end, can define the success and stability of the product, the time to market, the complexity of operation and a whole host of other results. Day-to-day decisions made by team members can have huge long and short-term impacts on the future of the product and the company.

The ethos also helps to define the culture of the team, how they work together and their common bond.

In thinking about this, I came up with this list of principles that I think all engineering teams should be guided by:

Measure Before You Cut

I will be the first to admit that early in my career, I was a very chaotic engineer. I had a massive amount of energy but a complete lack of focus. But, fortunately for me I worked for some really good engineering managers that forced me to learn and realize two very important things – work smarter, not harder and most importantly, make a PLAN for everything you do.

I think it’s important for a team to understand that it is not a sign of weakness to endeavor to discuss how they plan to attack and solve a problem, or implement a feature. Feedback from friend’s experience leads me to believe that there are some development environments where doing this is a sign of weakness, a sign that you need “help”.  Which leads me to the next principle.

Communicate

I cannot stress enough how important communication is within an engineering team. When I am interviewing candidates, one of the first things I ask myself is “is this person a good communicator”. The ability to express ideas and share them coherently with team members is critical to the success of an engineering organization. Because, as you scale, you will need your initial ranks to educate those coming forth, you will need team members that can offer visibility to what they are building to sales, business development and marketing.

Focus, Focus, Focus and Type Often

Ever chased the end of a rainbow? Well, you don’t need to know what that is like if you have ever worked for an early stage startup’s product team. You are going to make mistakes, nothing is ever as well defined as it can be, plans and direction will change from under you, your customers may not like the first version of the product, etc, etc, etc. In order to combat the realities you face as an early-stage engineering team, you need to have intense focus during core initiatives. Without that focus, you will be pulled into distraction and chaos.

Type  Often

A friend of mine once said: “If an image is worth a thousand words, then a prototype is worth at least a million”. True validation comes when people use and experience your product. So, getting your idea into people’s hands, even if it’s just your friends and family is an important endeavor. This same principle goes for every single sprint in your development road map.  Every second of a startup’s lifespan counts and if you’re not typing, then you’re not moving towards the next substantial moment when people will experience what you are working on.

Be Open

It’s important to recognize that all people need to know what the mission is. Far to many organizations are run by people who believe them selves to be king or queen of a fiefdom. They tend to be information hoarders and they believe that if people know too much about what is going on it will somehow erode their climb to the top of the illustrious ladder of success.

In other situations teams are run by people who are simply bad communicators. Thus , there are cascading effects that are only realized when it’s too late (usually a few hours before your investors replace you).

It’s important not only to be open and share what’s going on with the team, but also embody in everyone else that it’s important for them to do so as well. This needs to be a guiding principle, top-to-bottom, throughout the organization. Share forecasts, share revenue numbers, share potential business development deals, share strategies cross functionally; engineering needs to know how the company is intending the sell the product, as well as the sales team needs to know how the product is deployed and maintained.

Know Your Role, Declare What You Want

A headhunter once told me: “You need to show new engineers that there’ s a way to the top, everyone wants to be a manager”.

I think this is rancid thinking. Yes, everyone wants success and to understand how to grow within an organization. But, I think there is a crippling concept that has acidified the minds of young engineers; true success is in management.

To me, this is simply the result of inbred thinking and the lack of a good team ethos. Success is when your product succeeds and in order to get there, everyone working in the team needs to know how they fit into making that happen. If everyone is gunning for a “bigger role in management” they will miss sight of the important role in which they are responsible for today.

It is, however, important for your team members to know they need to regularly declare where they want to go want what they want to do. They need to let the current management know what type of role they see themselves playing as the company grows. I have seen way too many team members keep this within, expecting their leaders to be able to look into a crystal ball to know what they are thinking. Over time, this tends to be why good engineers leave – they perceive no growth opportunities for themselves but have never communicated that with anyone.

Know How (and when) To Celebrate

In startups, there can be many ups and downs. In small startups, I think it’s very important for the team to know what a “win” is and when to celebrate. For us, a “win” is when we launch a new feature, do a major version release, get some good press, or fix a major bug.

I’ve been in situations where teams celebrate way too often; Tue and Wed are hump-day “long lunch days”, Fridays, come in at 10 and leave at 4 for beers, etc, etc.

Momentum is critical for the success of a startup. Gains in momentum are all incremental – your win is the product. The more you focus and push for gains in the product, the more you win. It might mean missing beer night, or eating lunch at your desk. But, in the end, when you’re hanging out at SXSW and having beers with the team, postponing those long lunches will seem well worth it.

In the end, celebrate when you truly win. Which, leads me to my overall team Ethos:

WORK HARD, PLAY HARD, CARE HARDER

(please excuse typos, wrote this on my Android)