As I am starting to look for my next opportunity, I have been chatting with people and thinking a lot about what makes a great team, because, hey call me crazy, but I want to work on a great team!
Aside, a projection.
A method without a name. A mixture of common sense, measuring, validating assumptions, trying to constantly improve, and deliver value.
Buzzwords tend to be oversimplifications. Once you name it, people can misuse it, and mis, and dis, and over credit it. A name is a simplification, a reference for convenience, but also a source of ambiguity and misinterpretation when there is something complex behind it.
The Stage
Looking for patterns of what works well in software development and makes teams great, it is all to easy to focus on a narrow context or anomalies. Some learnings are only applicable in a narrow context, and some things work just because of luck, timing, or insane talent, but I've always been interested in what basic truths can apply to the wider context. I've been lucky to be a part of development teams in some wildly different companies: enterprise, bootstrapping, seed startups and series A/B startups.
Some patterns emerge.
In some large enterprises, failure is the ultimate fright. Methods for developing software stray towards avoiding failure more than focusing on producing the most valuable results with a managed amount of risk. Over time, in the past, many decisions were made to attempt to reduce project risks to zero. Those decisions build up into a 'mountain' of processes and procedures and risk reducing minutae. Ironically, many large scale projects still fail even with all this 'insurance'. The large companies escaping this antipattern have typically, through luck or drive of motivated individuals, hired some amazing people, and sometimes even partitioned them off from the 'mountain' so they can move faster and with more impunity.
In startups, the risk of failure is not just the project, or the jobs in one team, but the entire business. There is generally not enough time to build a 'mountain', so the approach to managing risk is to validate the product/market fit and value delivered, constantly. Imagine that your whole company rides on continual best guesses that can turn out to be wrong. And when you hit a 'wrong' streak, it may go on forever until you go out of business, or it may get better tommorrow based on what you learned! You have no way of knowing. Getting things wrong a lot can be demoralizing for many kinds of people. Having one's beliefs and convictions challenged and overturned is not the sort of thing that excites most people to their very core. It takes a special kind of psychopathy to get jazzed from continually pivoting and adjusting based on what you discovered you did wrong. The startups which escape that psychological black hole and grow, are the ones which can find and hire amazing people that can embrace that challenge with rigor and excitement, together.
Which brings me to my ultimate point . . .
The most important thing you can do to consistently breed great software and the teams that produce it is choosing great people that have an interest in doing their jobs excellently and making amazing things together
If you optimize anything, optimize your hiring pipeline and process first to find and hire great people that can work well together.
It affects every interaction and unit of work that a team creates for as long as those hires are present.
Team set, match.
Whether you've recruited your dream team or are still working on that, I propose these maxims that seem to work well across companies of all shapes and sizes. They are not policies, procedures, specific tools, or techniques. They are starting points to be flushed out in a way that makes sense for your environement. My ideal environment would embrace them all as fundamental.
- Bold, cohesive, widely understood vision with an owner People need something exciting to shoot for and when questions come up along the way, they need an well-understood purpose to use as a guide, and a responsible entity to go to for tough decisions. Go bold, but not crazy. We all have have an innate sense for discerning the difference between hmmm-this-might-be-possible-and-is-therefore-exciting and hey-this-guy-is-nuts-this-will-never-happen-what-is-he-smoking.
- Right-sized Feedback Loops Make sure the software you build gets validated by the people that will value it, at the right point in time. Build it to the level of completeness that it will excite and encourage use and feedback. Build and deliver with confidence because you did the appropriate amount of testing to retain confidence that a good experience will be had by any user. Right-sized feedback loops should prevent boondoggles, and validate value early.
- Predictability and Focus Prescheduled times for meetings/planning/breaks/etc create a rhythm of predictability. Developers need focused uninterrupted time to work on implementing tasks to accomplish clearly spelled out goals. Predictability of interruption is what allows periods of focus.
- Openness and Honesty Encourage Openness by never penalizing honesty. If a task took twice as long as expected, it's an opportunity to learn and adjust. Be careful of tracking individuals' performance on arbitrary metrics. You don't want people fudging numbers to fit in or avoid getting in trouble, or make their quarterly bonus numbers. That throws off making the entire team more efficient and effective.
- Passion Always encourage going above and beyond when someone shows the interest, even though not every instance of it is a win. If people get the sense that failed experiments are failures, then they will stop experimenting. If they sense that mediocrity is the norm, then mediocrity will become the norm, and people will pour their available passion into other things.
- Efficient is not necessarily Effective. Learning and Improving is progress. You can have an entirely efficient development process with tight feedback loops among dev and qa, estimates matching actuals, people working predictably and not burning out, and regular releases going out that don't have major problems. However, until you market test it with your users/customers, you can't be 100% sure you built the right thing. A market test where you learn something is progress. Re-enforce that at every opportunity because the alternative is stagnation.
Did I miss anything?