You may be an engineering leader just starting out in your career or you are a battle-hardened veteran with scars to show.
You may work for a small startup out to disrupt the world or a large organisation that directly impacts millions of customers.
You may have just formed a team or have a well-oiled machine as your team that can fire on all cylinders.
You may be building a customer-facing product or building an infrastructure used by internal teams.
Irrespective of your situation, here are a few dysfunctions you should watch out for.
Lack of prioritisation
Your team is always asked to do more than what is possible (if not, you have a different kind of problem!). In fact, you are bombarded with requests from your business stakeholders, your product managers, scaling challenges from existing products, and operational problems with running your software. It would be easy to plan as you go and make just a little progress on all these fronts, keeping everyone happy. Even teams with a good planning process might fall into this trap of doing a lot of things at the same time.
What is wrong with this? The important initiatives that you care about never seem to get done, only the squeaky wheels get oiled, your team is at a breaking point since they context switch constantly and your end users are dissatisfied.
Here is my approach: create a planning process, if you don’t have one already. This is where you partner with your product team to get the most important priorities from the business team. Talk to your engineers, who know where the bodies are buried, and build a technical roadmap. Add to this, any other strategic initiatives your leadership and company are aiming for.
As part of the planning process, I like to identify one or two results I really want to achieve by the end of the planning period. This is where I and the rest of the team will be spending the majority of their time. The rest of the time is split between planned maintenance, ad hoc requests, and experimentation/innovation. Roughly similar to the big rocks, pebbles, and sand analogy.
Outputs over outcomes
Outcomes are what your business wants to achieve. Outputs are actions that contribute to achieving them. They are means to an end, not the end itself. You may find teams are consumed by the day-to-day delivery aspects, only to find that they have lost sight of the end goal in the process.
Too often, engineering teams obsess over the product, architecture, technology stack, and release process. Once a product gets released, they might move on to the next important thing on their backlog. But it takes time for a released product to achieve the business goals, which may or may not happen. Maybe you want to help customers discover your catalog faster, reduce calls to the call center, improve marketing efficiency, reduce friction points in the customer journey. Just because you have released your platform doesn’t mean you have achieved any of your goals.
That’s why it is critical to identify your business goals early enough and communicate that to the engineers. Frameworks like OKRs clearly help you in defining and tracking them. Involving the engineering team early in the process means they are vested in the goals and work towards achieving them.
It’s not just your final product that should achieve your business goals. This big bang approach is not in the spirit of agile. Rather, every step of your delivery – your milestones – needs to take you closer to your objectives. Thin slicing is an effective technique where constant feedback helps you be always aligned to your goals.
Operating in silos
A team is a group of individuals that work towards a common purpose. It is important that the team understands this purpose and work collaboratively to achieve this. A team can work on multiple work streams in parallel, but this can get out of hand sometimes.
I have seen real-life situations where a 5-8 person pizza team has more than five work streams. This means the team no longer collaborates and is effectively working as individuals/smaller teams. Not good for resilience or knowledge sharing. This all started with a broken planning process – a list of initiatives, assigning a certain number of engineers to each one of them. This sets an artificial expectation that a lot of things can be done in parallel, when in fact it’s not a team anymore.
This dysfunction can also exist in groups of teams, when teams focus solely on their respective team-specific goals, but not their overall tribe. There are individual pockets of excellence and team-specific challenges, but thanks to a lack of information sharing, the excellence doesn’t get shared and challenges don’t get addressed. Technology forums, guilds, and effective inner sourcing are some ways to address this challenge.
Product work and Technical debt split
Maintaining a platform is expensive. When you have a platform that’s at least a couple of years old, there is an increasing cost to just keep things running. Teams start to think of building new features (“product work”), separate from paying back the accumulated technical debt. I would argue that these should be one and the same.
Great product managers are storytellers and start with the “why” when introducing anything new to the team. Similarly, technical debt should be planned in advance, leading with the “why”, not the “what”. They are not two separate lists – they should benefit the customer ultimately, so it should be one single list, evaluated and prioritised using the same process.
To wrap this all up, there is a famous model that delves much deeper into the underlying causes of team dysfunctions. Mine is a collection of personal observations for engineering teams, that lists some symptoms leading to a deeper deliberation. Keen to hear your observations.
Article written by Chandri Krishnan, Head of Engineering at Just eat Takeaway
Interested in DevOps & Engineering? Why not come to our National DevOps Conference in June? 🤩
