How are we building a high performance engineering team at marketgoo?
One of my goals as Head of Engineering at marketgoo is to build a high performance team. To accomplish this in a product development context, we first needed to remove the eternal “tech vs. business” confrontation through a common companywide vision.
Not having this shared vision was making us less efficient and it has been a huge frustration for me. Talking with other CTOs, I discovered this was something common in many companies with software development teams. Recently this topic came up in a Tweet with @stanete and @flopezluis and it pushed me to share my impressions about it just in case it could be useful for others:
Sometimes engineering teams are frustrated due to different reasons: they feel they never have time to improve technology, they are always in hurry and overcommitted, they feel they are always commanded by other company teams, they feel they are not trusted. At the end of the day, the engineering team has become a ticket factory without motivation or understanding because they do not understand the business.
On the other hand, the product or business teams are often frustrated because they do not understand why engineers are so eager about technology details and not about value or business metrics. Why are they pushing to improve the cache system instead of adding this brand new feature? Of course there is a reason. Engineers will always bet for technical improvement. It’s our domain and if we do not understand the context, we will focus on what we know.
This is what I call the “Misalignment anti-pattern”, and it happens when teams work in silos without a common understanding of the company momentum.
It happens that there is a business development plan, a product plan, an engineering plan, but not a common global plan. Maybe there is one, but nobody knows it outside of the C-Suite (this is another topic).
What I experienced is that having a common plan and adjusting the plans of every team to this main plan, makes a huge difference. People are more engaged, and they find a purpose in what they do.
Do you think engineers have passion for changing a text or a button color? Of course not, and that’s what they think they are doing when they just take the next ticket to work on it and pass it to done without any further understanding. But what if they understand that this little change will improve the product conversion rate, and it will make the company make more money, and this will also increase the employee wellness? Then, magic happens, and they get a purpose. They are not changing a button anymore but improving the company revenue and their own wellness through a common company goal. (There is also a powerful alignment between self interest and company interest. We see the company as a vehicle to reach the life we want to live.)
We experienced this case in marketgoo. We are obsessed with organization and methodology for everything. Nothing is casual. The problem was that everyone had their own organization and plan for his team. Since we worked on a common vision, we immediately detected this problem. We started to ask ourselves “why” for everything and many times the answer was “I don’t know” or “I feel this is good” instead of, “This is aligned with our vision and goals” or “This will improve that metric from our plan”.
Imagine the impact this can have on a development team that was feeling they were just providers for the company. Now they understand the common goal, they are more engaged and they are growing like never before in ownership and accountability. They are even challenging product or business ideas like: “Why should I work on this feature? What’s the goal behind this change? Can’t we do it like this instead…?”
We ended merging the product and the engineering teams into a “Product development” team. This, together with the “Shape Up” methodology and having a common vision absolutely turned our software development team from a factory to a high performance team that constantly adds value.
Don’t think this means we are not doing technical stuff anymore. We do even more than before, because the technical projects are aligned with the company goals. A good example is this cache improvement again. It’s something very “techy”, but we estimated that if we are planning to add more KPIs to our product (KPIs in the context of our product are the most important SEO indicators a website owner needs to monitor), the amount of stored data per plan will increase, and this will slower our performance, so at the end, this improvement is helping the company to reach their product vision goals instead of being a problem. This also works in the opposite case. Engineering stopped to propose technical changes for the sake of it, because they see the value it adds and the goal we pursue as company. While they understand why we do something or not, frustration vanishes.
To accomplish this, we analyzed the company momentum, the engineering momentum and aligned both of them.
Company momentum
How to find out the company momentum in a simple way, so every team in the company can understand it and adapt to this situation?
Like Kent Beck explained in his “3X Model”, there are 3 common company phases and depending on the company phase, your engineering behavior has to adapt. Those phases are:
- Explore: This is a experimentation phase where we try to figure out how to build a business
- Expand: We already have a business in place and we need to consolidate it and figure out how to make it profitable.
- Extract: When the business is stable and the only thing to do is to fine tune details.
Usually you are in Expand phase when you reach the “product market fit”. In our case in marketgoo we can consider we are in Expand phase and we are working on the Product Vision to consolidate and enter the Extract phase. We are having a good growth, but we are far from the Extract phase.
This is a fat marker view of your company situation. As Engineering leader, your peers from the board should help you to understand in which phase your company is. Understand the problems in the product, understand the business metrics and when you have a clear vision of the phase you are experimenting, go ahead for the next step and think on the engineering momentum.
Engineering Momentum
Now focus on the engineering team.
Like Roy Osherove explained in his book “Elastic Leadership”, there are usually 3 modes for engineering teams and they match like a charm with Kent Beck’s “3X Model”.
During the Explore phase we need to understand that there is no point for code excellence or fine tuning. When you explore, you need to survive and save resources for experimentation. You don’t have a big team that can do a lot of things at a time, and those explorers are in “Survival Model”. Explorers do not have time to learn new stuff, they are constantly putting out fires and they are usually late and overcommitted. In this mode, the motto could be “Don’t worry, be crappy” (Thanks to @buenosvinos for the quote).
If everything goes well and the business starts to consolidate, it enters the Expand phase, but the engineering team remains in Survival Mode due to technical debt and the past trends. If the company enters the Expand phase, the engineering team needs to change their behavior to enter the “Learning Mode”. Engineers are no more explorers trying to survive. Their new goal should be to efficiently productivize the technology so the business can grow. There is no more room for improvisation, and decisions should be based on a specific goal: to add value to the product and reach the “product market fit” as fast as possible. This is what Roy Osherove called the “Learning mode” for engineering teams.
The “Learning mode” is a transition to reach the “Self-organizing mode” during the “Extraction Phase”. While in “Learning mode”, engineers need to have time to do things right, to learn, to grow as professionals, to innovate even if they make mistakes… How to transition from “Survival” to “Learning” mode? Roy’s answer is to remove overcommitment and allow slack time. But this statement sounds a bit abstract. How can we add slack time and remove overcommitment?
I will focus on this phase and mode, because in my experience, there is where this “Misalignment anti-pattern” usually happens. If teams are in “Self-organizing mode” during the “Extraction Phase” it’s usually because they already transitioned through this situations.
From a company perspective, you can define a clear vision to improve focus. We used EOS methodology at marketgoo and the V/TO exercise was a total game changer.
From a team perspective, switching from Scrum to Shape Up helped a lot to focus on the stuff related with our company vision.
From an engineering perspective, even if we focus on the relevant things, there is still a need to improve and adapt the technology to changing company needs, and we also need to keep maintaining the buggy Exploration phase code. Even if we adjust our focus and our methodology to be efficient, there is a limit in what a team of humans can do.
At this point we should think: What’s the opportunity cost for not producing the value the market demands? In other words: ¿How big is the opportunity cost of not having critical products or features in production and ready to sell?
If the opportunity is not that big it’s fine. Just focus on other things and don’t do it, but if the cost is too high, then maybe it’s time to scale up the engineering team to produce more value.
Time to scale up the engineering team
If you are in this situation you are probably in need of shipping new projects, improve your current product/project, do maintenance and pay technical debt.
This is the 3 steps strategy to create slack time and reduce overcommitment we are applying in marketgoo right now.
- Slow Down. At the beginning the team does the same work as before and handles the onboarding of new members.
- Stabilization. When the new members are ready to accomplish tasks alone, the team can start to solve technical debt at the same time the product evolves. The team accomplishes the product evolution tasks without new debt because there are more people working on the same amount of work. The tackled debt is mandatory related with the product roadmap.
- Speed Up. When the biggest pains of the “Survival” debt are paid and our technology is ready to fulfill the product needs, the new members can start to work on product evolution with the rest of the team and the bandwidth will increase, speeding up the whole team.
More people in the team means more people for the same amount of work, driving to more slack time for every team member. This time will be spend thinking and doing things without dangerous shortcuts and allowing the team to pay the debt acquired being in “Survival Mode” during the “Exploration Phase”. This extra time will also allow the engineers to measure and plan their work instead of improvising from fire to fire.
Remember, it’s no more time to be crappy. We need to consolidate our technology because we are in Expand phase. This consolidation will be our foundation to enter the Extract phase.
How to optimize the team growth to increase the value production? Balancing the engineering team costs with the value production capacity. The best way to optimize the costs is to have the right people in the right place. It does not have sense to hire a super senior engineer with 25 years of experience and a salary over 70k/year to fix typos or change button colors, so a wise chosen combination of experience diversity would optimize a lot the expenses. Juniors doing simpler tasks, experts increasing the value in complex features or products, and leaders challenging the focus and the “Learning Mode” transition.
Learning Mode
Once the team has scaled up and has more time to learn and plan his work, we need to provide the team with the right tools to do their job. The tools that help the company to reach his goals. If our roadmap implies a transition to SPA, the team needs to learn about SPA or GraphQL. If we need to improve our cache system, maybe they will need training in Redis.
What we did in marketgoo is to provide the team with this knowledge. They will have every Friday after lunch a training session. Every week a different team member will prepare a relevant topic for our roadmap to train the team during 1 or 2 hours. This requires not only the team to have time to participate but to allow the trainer to prepare the topic during the week. This is a good use for the slack time mentioned before. We got a lot of inspiration about this from the Triporate team.
Technology Roadmap
Even if the engineering team scales and reduces the debt, a plan for the future is a must, and this plan should be aligned with the company needs and the Product Vision.
I have seen so many technology roadmaps focused on the technology just for the sake of technology…
A good and efficient Technology roadmap should be related with the product roadmap to anticipate the needs of the system based on the product plans. There is no sense in planning shiny technology improvements nobody will use or notice. If your company plans to expand to other markets, maybe you should plan about platform scalability to support more users.
Putting it all together
Once you have a clear vision of your company phase and your team mode, match it all together to move forward. This is our recipe at marketgoo to fight this “Misalignment anti-pattern”:
- Align expectations companywide
- Focus on relevant stuff for the company and not only for technology.
- If you have the resources, scale up the team to fulfill the company needs and to optimize the investment.
- Give the team the tools to improve (slack time, trainings, methodology iteration, etc).
- Define a clear roadmap related with the company needs.
2022 Update
Everything detailed in this post was put into practise for at least 2 years and it’s gone extremely well for us. However, our flexibility and ability to adapt the way we work according to our changing needs has always been one of our best qualities as a team.
We’ve continued to iterate and improve our processes, always aiming to have a shared purpose and a clear vision for everyone.
To get closer to that shared vision, we have to meet certain objectives like providing a service to our Partners that meets the highest standards, expand our existing business and diversify by opening up new business lines.
One of the changes we’ve made is to restructure the Product Development team. During the past few years we’ve doubled in size and we’ve restructured the team into cross-disciplinary “squads” for each business line.
This structure allows us to truly focus on our objectives and for each team member to hone in on their mission:
- The “Existing Business” line grows our current business by improving our products, supporting our Partners and testing new expansion strategies on the existing client base.
- The “New Business” line researches, tests and validates new business lines. This means working on hypotheses, testing and leveraging them if there is market traction.
- The “Platform” team maintains our technology and provides tools and resources to other teams. All our products leverage our platform and have to run smoothly.
In order not to create knowledge silos, team members can change teams every quarter and we organize monthly meetings in which the teams show what they are doing, and the results they are obtaining to the other teams (a.k.a. Townhall meetings).
Another interesting change that we have implemented is a methodological change. We are huge fans of Shape-Up and it is the ideal methodology for long-term sustainable product development, but it is not the best option for rapid experimentation and iteration.
At this time we have opted to experiment more, so a more agile methodology suits us better. We have adopted the principles of Extreme Programming to have shorter feedback loops.
So far the result has been spectacular and the team members feel that they have a greater impact. They have gone from passengers to drivers.
Seen in the company Slack: “Organizing by squads is the best thing we’ve done in years”.
Wanna know more?
I wrote this based on my experience, describing what is working for us in the context of a small product company. If you are in a big services company, this may not fit your needs.
If you want to know more about marketgoo and our culture, we are always up for a chat. We would love to hear your experiences building high performance teams in your companies.
