We’re just past our quarterly update excercise where we decide what to build over the next 3 months. The team has grown again, from ~80 revolutionaries last quarter to about 130 now. Reflected on a couple of learnings about high performing teams.
- you can’t tell the team what to build
- organise teams behind company goals
- keep teams small and independent
- supply the vision
Nothing matters more than speed in a startup. Removing friction and giving clarity around the vision and goals pays off like nothing else.
1. Don’t let the board/cxo/committee have an opinion on what the team should build
Having recently been through a number of VP Engineering interviews, I’m stunned about how many organisations rely on the wise men on their board to strategically decide, what are the features that the company should build. The success of the CTO is then determined by how she hits the original agreed timeline. It can only be luck that keeps such companies still in business.
What’s wrong with this? People who decide what to build are far removed from the customer and the people who build are measured on “hitting the plan” and not on value they create for the customer. Boards, founders and executives can have an opinion about the vision (see point 4), but not about the features or tactical decisions.
Teams must be able to come up with their own plans and features to build. They must be “full-stack” enough to appreciate the benefit they bring to customers, to analyse the data and to think strategically a few years ahead.
When interviewing a candidate engineer, we always check what happens, if there is no-one there to tell the engineer what to build. How do they start thinking, researching and prioritising the problem.
2. Organise teams behind levers of the business
We started getting considerably more internal stress about the time when we hired our 10th engineer. We had long roadmap discussions where we tried to work out collectively how to prioritise the important features, markets and customer segments. Relief came when we decided to split the product-engineering team into 3 and give each team their own company-level goal. We figured that TransferWise will be success if we a) convert new users; b) build a fast and efficient payment engine; and c) help the product spread virally. Each of these three levers became a product-engineering team.
The word “roadmap” didn’t come up any more, we reduced planning meetings 3x. Everyone suddenly knew what they are building and why. They created their own KPIs to measure weekly and monthly how much impact they had on our overall success.
We try hard to measure the value that we create for the customers, not so much the commercial vanity success. A good contrast would be increasing the speed of payments by 20% vs. increasing the fees by 20%. The lever that makes a difference at a grand scale is going to be the speed.
3. Teams perform best when small and independent
Our team structure has now evolved even further. We extended the product-engineering concept across the whole organsiation, so that now almost everyone belongs to one of 7 themes, including engineers, payment operators, customer service agents, marketeers, finance. The only “support” are office managers and recruiters. Each theme is full stack and has their own company-level KPI that they are improving.
Each theme can do their own magic and they don’t rely on anyone else to succeed with their KPI. For example, an engineer working on a user experience may decide that it is OK to release a half-baked feature, if his customer service colleagues are willing to help with call volume that this may cause.
Founders must tame themselves not to design the product, but create the structure of full-stack teams and measurable KPI’s. So that the entire organisation can act as enterpreneurs.
4. Then there is vision
Although founders should abstain from designing the product and proposing plans for the teams, they do have a responsibility for the high level vision. Why? Because if the startup is still alive, then they must have gotten something non-trivial right in the early days.
The vision is understanding and explaining, what makes the product great, why it is needed and what is its place in the future world. The vision is both the insights from the past and the forward-looking statements about the future. The vision explains why the company exists. Every startup needs to institutionalise their value proposition and the mechanics that have gotten them traction. It is the job of the founders, the board and later on the senior leaders to explain that vision and create the structure. The structure where sub-teams can make their own plans, design the product and have their own customer feedback loops.
The tricky part is managing the expectation between the longer term company vision, which takes advantage of the original insights and imagines a niche in the market, and more specific product vision, which should be bubbling up from the teams.
Things we haven’t worked out yet
- How to self-balance resources between sub-teams? Focus shifts between KPIs. Would like to avoid asking engineers to switch teams, but rebalancing will be needed. Self-balancing teams are not new. Read about Valve’s desks on wheels, and Pandora’s voting with time.
- The KPIs don’t necessarily match the way that the systems and code have been set up. How do you match the ownership of code with the ownership of KPIs?
- How to avoid matrix management in the context of geographical management, e.g. country managers? Do you create independent country teams, or keep the reporting lines functional.
Of course 200 people team will be different again, but that’s not to worry about now.