At some point I stopped being scared of software. Given enough time and money I could usually work it out. That pushed my attention toward leadership and the human systems around the work. I was getting more senior and getting asked to lead small teams, so it was a natural shift.
Reading Tom DeMarco put language to something I was already circling: the gelled team. A gelled team is not just a group of competent people on the same project. It is a team with trust, momentum, and a shared identity. Communication gets easier, conflict gets cleaner, and people start protecting the work because they feel they belong to something real.
That kind of cohesion does not happen by accident. It needs stability, real safety, shared ownership, room for deep work, and some sense of identity. Most companies quietly destroy all of that and then wonder why the team never really forms.
For the sake of this essay, identity is the part I care about. As a young senior engineer it was the most obvious lever I could pull.
Flamingo, an established startup aiding large financial firms in acquiring and retaining customers for complex products like Insurance and Mortgages. I was hired into an already established team. There were two Juniors, another Senior and a Product owner. We were tasked to modernise the PHP stack and break it into microservices.
When I arrived the team was still being forced into the “We’re all a family” lie that startups use to extract some free loyalty out of their people. It was here that I modified DeMarco’s original parameters into a more refined position where a team needs three things to form. A shared space, a shared goal, and a shared identity.
Shared space matters more than people like to admit. A team needs a physical place that is recognisably theirs, a desk bank, an office, some bounded territory that is meaningfully distinct from other teams. Humans are territorial animals. We organise ourselves around proximity, familiarity, and repeated contact, and when a group occupies the same space long enough it starts to develop its own norms almost automatically. Shared goal matters too, but it has to be narrow enough to mean something. Company goals are too vague and too broad to produce real cohesion. A team needs a task that belongs to its domain, something specific enough that ownership can form around it. And then there is shared identity, which is the closest thing to DeMarco’s original position. It is the sense that this is not just a temporary collection of workers, but a real unit with its own character, standards, and sense of itself.
Unable to move too far from the company identity I leaned into the Flamingo thing. We were a band of flamingos working together to bring this beast of a MVP into something that could scale with the ambitions of the CEO and CTO.
As the microservices started to take shape, we decided they needed to be containerised. Docker gave us a way to keep the growing system coherent and manageable, but more importantly it gave us a visible milestone. We were no longer just talking about modernising the platform in the abstract. Something concrete was emerging. Around that point I had the idea to commission a piece of digital art as a commemorative poster for the team. This was before generative AI made images effectively free, so getting something made specifically for us felt deliberate. The final image was absurd in exactly the right way: a vast whale pushing through rough water with shipping containers on its back and a few flamingos perched on top of it. It captured the feeling of the work better than any project plan ever could. We were taking this huge, ungainly thing and trying to make it move in a controlled direction. Looking back, that was the moment the identity piece really clicked for me. The poster turned a technical milestone into a shared symbol. It gave the team something that was unmistakably ours.
When we hit the milestone, I presented the poster and the team were genuinely chuffed by it. After that, the identity started to stick in small ways. “Alright Flamingos, what’s for lunch?” Little jokes, little references, little signals that this was becoming a real unit rather than just a reporting line. I was trying to apply DeMarco’s ideas where I could and, without quite realising it, I was slowly becoming the team lead without ever being given the title.
The problem with evolving into that role organically is that you usually run into resistance when someone else already thinks they own the position. In this case the product owner had cast themselves as the boss of the team. They were completely non-technical and were applying SCRUM in a way that some would call tyrannical. To be fair, most SCRUM implementations deserve that description, but I digress. Seeing that the engineers were responding to me, I got a little too big for my boots and started challenging this team-lead-scrum-master-product-owner hybrid on their approach. Usually in public. Always ineffectively. Looking back, it was a terrible way to handle it.
A second milestone was coming up and I decided to try the poster idea again. I cannot remember exactly what the milestone was, but I am fairly sure it was a management console for the microservices, a kind of DevOps backend to give us visibility into the system before Kubernetes had gone fully mainstream. One of the engineers came up with the idea of an octopus, something that could get its tentacles into every part of the platform. I pushed that concept a bit further and imagined it as a war octopus, a giant lumbering beast looming over the battlefield while the flamingos moved around beneath it. The image was commissioned.
I never got the chance to present that one properly. After a few confusing meetings with the CEO, a classic founder move of skipping the chain of command, I was told in the vaguest possible terms that “you earn the right to be yourself.” Not long after that the CTO took me into a room where the CFO was waiting and I was asked to leave the company. As it turned out, the scrum-lead-owner hybrid was friends with the CEO and I had pushed one too many buttons. The CTO looked unhappy about the whole thing and summed it up with “You’re one of the best engineers I’ve worked with and I don’t want to see you go but the harmony of the team is more important” and did what he could to soften the blow, but the result was the same. I was escorted from the building a lot wiser and a bit more humble.
Back on the market, it did not take me long to come across Snappr. The idea was simple and very of its time: an online marketplace where you could book a photographer instantly and they would just show up with a camera. It was basically “Uber for photographers,” which at that point was almost enough on its own to get a startup taken seriously. Still, it was a neat idea and, more importantly, it had energy behind it. They were looking for a heavy hitter to build a prototype of the marketplace while they were applying to Y Combinator, and I walked straight into that pressure cooker.
The submission deadline was three weeks after I started. There was no time for elegance, only momentum. Armed with a static design, a blank editor, and a completely unreasonable amount of ambition, I built the best vertical slice I could inside the constraints. It did the job. We got into the program, and almost immediately the problem changed shape. The next task was not to build the prototype, but to build the team that would build the company. I had one month to put together a dev team made up of people willing to spend the next six months in another country. That was where the real test started.
A lot happened in that period, but the biggest takeaway was that I learned what really motivates engineers. A motivated engineer is worth far more than a theoretically perfect solution. I learned that the hard way after pushing one of my guys too hard with my “we do it the right way” attitude and watching him crash out. I also learned that founders do not care much for structure or correct reporting lines. Everything is theirs in their mind: the company, the team, the success, the story. If they want to reach past the org chart and grab the steering wheel, they will.
Snappr was where I got to build a team from nothing and shape the culture around it in real time. It was also where my leadership style started to solidify into something recognisable. Protector is probably the best word for it. I discovered that good engineers genuinely love the work. Left alone in the right environment, they will build, explore, and obsess over the craft quite happily. My job was not to stand over them pretending to be the smartest man in the room. My job was to find the environment they thrived in and defend that bubble fiercely from the rest of the company. That instinct has stayed with me ever since. After twelve months, they wanted me to get an E3 visa and move to the US to keep building the platform.
Before the move to Silicon Valley, the plan was to rent a big house and live and work together. I remember saying, “This will make or break the company. We’ll either come out of it as brothers or we’ll hate each other.”
It was probably one of the greatest opportunities a young engineer from a backwater like Australia could have been handed. I decided to stay in Sydney and wished them well. Six months had been enough to show me the raw underbelly of Silicon Valley and all the usual VC shenanigans.
That led me to HealthEngine. This time it was not a scrappy startup but a scale-up with a mature product and an established way of doing things. They were based in Perth and wanted to spin up a satellite office in Sydney, partly to deepen their presence there and partly to tap into the talent pool. I was brought in as the tech lead for a skunkworks team whose job was to explore new products and find product-market fit adjacent to HealthEngine’s existing offering.
This was where I deliberately combined what I had been learning at Snappr with what I thought I had proven at Flamingo. The result was the trust coins model. The basic idea was simple: as a leader you have a limited amount of goodwill, and you spend that goodwill whenever you ask people to eat shit for the company’s sake. You earn trust coins by giving people autonomy, letting them own meaningful work, protecting them, and treating them with basic human respect. You spend them with tight deadlines, overruling decisions, and the usual startup nonsense of “go faster and break more things.” The ratio is brutal. Trust is much easier to spend than it is to earn. That is where the art of leadership lives.
The complication was that HealthEngine already had established engineering teams in Perth, and a large company always comes with a large company’s immune system. The Sydney team quickly earned a reputation for being cowboys who “didn’t get it”, the team that would ignore established norms, disrespect the legacy codebase, and generally make a mess. They were not entirely wrong. We were less conservative than the Perth teams and, because most of our work was greenfield with the messy integration points handled elsewhere, I did not see much harm in it.
So I leaned into that reputation. If we were going to be treated like pirates, we may as well raise the flag properly. That became the identity. We put a pirate flag up in the office, joked in pirate voices, and turned the whole thing into a shared bit that was funny enough to be disarming and real enough to become culture.
And the point is that it worked. The identity leaked out of the office and into the rest of life. By the time a work Halloween party came around, the team were turning up dressed like pirates without needing to be convinced.
These are only two examples, but the identity was strong. I had a few opportunities to build up serious trust bank and, for the most part, the team was gelled and naturally looked to me for leadership. The trouble is that identities become threatening when they work too well. Over time the pressure from the rest of the company started to build. The Sydney team was too cliquey. Too independent. Too much its own thing. We started getting more mainline platform work, partly because there was useful work to do and partly, I suspect, because the business wanted some visible return on this expensive little gang on the other side of the country.
Then one of the team leads in Perth was promoted to engineering lead and I stopped reporting to the CTO. Fair enough. But that was where I was really tested. I had positioned myself as the interface between my team and the rest of the company. I recorded status videos, handled complaints, and absorbed the feedback so the engineers could be left alone to work. The new engineering lead wanted more visibility, not just into output but into the process itself.
He asked me to send him our velocity numbers every sprint. I politely refused. Velocity is an internal team planning tool. It is not a KPI. It should not be turned into a performance instrument for management to wave around. He was a new manager, dug his heels in, and we started butting heads. I tried to maintain the independence of the team, but when I pushed the issue upward to the CTO and founder the message I got back was basically: get back in your box, tell your guys what to do, and make sure they do it. After two months of that fight I decided to leave. I did not know how to resolve the conflict and I was making a mess of it. I had put the team and the cohesion we had built above everything else, and management neither wanted that nor valued it.
After I announced I was leaving, I came in one morning and found a sticky note on my monitor.
It said “Stefan is a dog” with a little heart next to it, which was, in context, about as affectionate as it gets. The team were obviously unhappy with my surrender and let me know in the sweetest way possible. I miss those guys. I will never forget what we had, and I still cherish that stupid sticky note.
That led me to the CTO role at Refilled. It started as the classic “we cannot really pay you, so here is a title” arrangement, and for a while it was just me, a solo engineer with a big mandate and very little structure. But as the team has grown, I have had the chance to apply these lessons again with a bit more maturity and a lot less ego. Not as vulgar as Team Pirate, but effective enough to create a small silo of sanity inside a chaotic, high-growth hardware startup.
That is probably as neat a conclusion as I can manage. Shared identity matters. I have seen it turn a group of engineers into an actual team, and I have seen politics, ego, interruption, and managerial insecurity break it apart just as quickly. Once you have had the real thing, the fake versions become hard to take seriously. Maybe that’s why I still think about the flamingos, the pirates, and that stupid sticky note.
You spend the rest of your career trying to build that kind of team again.