Imagine the scene, you're a plucky engineer with stars in your eyes and the promise of an open plain to help build an ambitious CI pipeline, a continuous deployment harness or a dinosaur-filled theme park. Then you start. And quickly realise that half the team want to build custom enclosures, another half want to reuse the triceratops enclosure and another half want the dinosaurs to roam free.
As companies grow, they often realise that they need a new team for something they could get away with adhoc support beforehand. Whether this is internal tooling, deployments or even operations as a whole, there comes a point where they need to setup a backbone team to support the organisation. Often, a company gathers some of their best/senior engineers, hire some experts and trust they all know what to do.
On a team of senior engineers, often with no manager, it can feel impossible to get things done. How do you fix a team that doesn't know it's broken?
The biggest obstacle you're going to encounter is consensus. With many experienced, often brilliant, people on a team, you also have to deal with conflicting opinions and long discussions. Everyone has sat through The Infinite Meeting where two people just talk themselves in circles and it is infuriating, frustrating and time-wasting.
In the absence of authority, without a defined process, it's hard to know how to choose an option. As engineers, we often believe that we can argue all the aspects of all proposed solutions until we've found an objectively good option but, in practise, this very rarely happens. We don't make decisions in a vacuum and tradeoffs are inevitable.
There is a piece of advice from a wonderful article by Roman Imankulov (which you should definitely read in full) that has helped a lot in particular:
If there is a good enough solution X, don’t ask people what they think about it. Instead, ask everyone if they can live with it and if not, why.
It reminded me a lot of The Marines' 70% Solution, with the idea that we use a basis for rough consensus to make decisions and curtail long arguments about non-critical issues.
With this change in questioning, conversation should only focus on fundamental flaws with what was proposed. We can live with small imperfections but flaws need to be talked about and solved.
Ideally, when someone brings forward a flaw, the feedback should be as clear as possible. This bit doesn't always come as easily to others so if you notice a team member rambling a bit or circling the issue, it can help both of you to be polite and ask "I think I understand what you're saying, do you mean..." And then restating the issue in clearer terms. Remember to be respectful of what people say and be prepared to be corrected if you've misunderstood - apologise and listen again.
Another way to help minimise long-winded arguments is to get a lot of the conflict out of the way before the meeting even begins. Design Documents are a great way to whittle down big decisions so that the only decisions to be made in the meeting have a yes or no answer.
I thought for a long time it was down to chance or team composition that design docs worked so well for me but then I read this great article about planning by from Vanessa Schneider, Isabel Tewes, and Laura Chambers and it had the following recommendation:
Get a single individual to take the first pass: Having a strawman proposal for a group to comment and iterate on is far more effective than a group developing a plan together in real-time.
Personally, Google Docs' suggestions/comments feature makes this super easy and I'd say this is probably the easiest way to ease long meetings - let the masterminds duke it out before the meeting.
The goal you think you're working towards may not be the same goal your colleague thinks you're working towards.
What does your team do? What is your team supposed to do? Without a mission statement, goals or an overall vision for the team, you will end up with people working towards separate goals and fragmented answers to both of these questions.
To solve this one, we borrow for the SRE philosophy and agree on objectives and how to measure them - Service Level Objectives. Our team should define measurable objectives for what we want to achieve.
Some examples of objectives:
At least 90% of new projects choose to use our standardised framework.
No more than 10% of deployments should require manual intervention.
Testing pipelines should take no more than 10 minutes.
The 95th percentile time (over 24 hours) of build pipelines should be shorter than 5 minutes.
This can be a good exercise in bringing people's subconscious priorities to the forefront. In allowing people to define and discuss different objectives, everyone can get a sense for what people think the team currently does. Does someone focus more on tight feedback loops? Quicker builds? Safer deployments?
Using our tool for making decisions, we can help whittle down all the objectives proposed and begin to understand where, collectively, we believe our priorities should be. Use these objectives to create a sentence or two which conveys the overall vision of the team.
The best way to bring a team together is through understanding, empathy and friendship. Forming any new team means taking people from other teams or the outside and pushing them together to make great things. The means that the team you've just formed are, ultimately, strangers when it comes to working with one another and they need to learn about each other as quick as possible.
My final recommendation is short and sweet: Do things the team members enjoy, together. Go for a meal; go see a movie; play laser tag; setup a competitive bowling team; whatever makes your dopamine tick - just do it as a team.
I'd love to hear your experience with conflict management and making progress on teams without a clear hierarchy! Let me know in the comments or reach out to me directly :)