In the tech jungle, you’d think that Tarzan swings effortlessly from one success to the next. But sometimes Tarzan falls – hard. We never see it, and he always gets up again: bruised and battered, but smarter. Here are some lessons from mistakes I’ve made in my career, which helped me to develop into the manager I am today.

Confession 1: I moved from a successful team to an unsuccessful one for no reason

Once I was a team lead in a perhaps unsexy but successful and growing area. Our team was performing well, delivering important projects, and taking on (lots) more responsibility. I got on well with my boss. I was coaching the junior leads and growing well in my role, with responsibilities beyond my level.

At some point, I became frustrated – for reasons that today seem trivial / business as usual – and jumped ship to the first open position I found. It was radically different, and that was exciting. However, this area was doomed to be shut down, due to strategic misalignment. If I had actually done any homework, I would have been aware that I had abandoned ship, to a sinking vessel.

If I had a time machine, I would have approached the selection of my next position as a major project, with appropriate planning and research, and invested time in getting to know my next area, my future management team, and the overall strategy and prognosis of the business. In short, I would have been clearer on what I was moving towards rather than away from.

Confession 2: I hired contractors and managed them like full-time employees

One of my teams was behind on a key project. The company experimented with hiring contractors. I jumped on the opportunity to add enthusiastic experts to the team. However, I made the mistake of embedding them fully in the team and treating them as full time employees. 

Why was this a mistake? Contract devs work and are motivated differently than full-time employees. They are temporary, they can’t be promoted, and they care mainly about completing solid projects for their portfolios. They work to the given specifications, and cannot lead projects or make strategic decisions. They do not have the opportunity to grow based on feedback given over a long term. Finally, they are dramatically more expensive than full-time employees. This means they needed much more structure and closer oversight than regular employees. 

If I had a time machine, I would carve out a separate team for the contractors, supported by a product manager and a senior engineer who would act as a ‘tech lead’, being responsible for the output of the team. The team would run according to a rigid structure such as Scrum “like you mean it”, with formal product management validation and verification through automated testing.

Confession 3: I went “solo” on a major project, causing friction between me and my leadership counterparts

Following years of successful hypergrowth, the company aimed to modernise its systems. I lept at this opportunity, having experienced the drawbacks of technical debt myself.

However, my leadership partners (product management, etc) were dead-set against the idea, resulting in a year of pushback, friction and misalignment – confusing the teams, stymying our relationships, and frustrating senior leadership.

If I had a time machine, I would have done two things differently. Firstly, to separate my relationship with my partners from the task at hand, emphasising that we shouldn’t let a difference of opinion cause a conflict between us or affect our teams. Secondly, to escalate the issue up to senior leadership, to make a call, when we could not agree. The fact is, people are motivated by incentives – while his senior management was not aligned with mine, naturally there would be disagreement. If we cannot agree, then our leaders would have to make a call one way or the other.

Confession 4: I made hiring mistakes on the engineering management team

As a newly-minted manager, my first priority was to ensure the teams had proper staffing; most importantly, leadership. But with the company scrambling, choices were few and far between. In some cases, I leapt too eagerly at candidates who looked great on paper.

After a few months, cracks started to appear. Teams fell short on delivery, the new hires were struggling, and I started to receive the kind of odd feedback from team mates that lets any manager know something is wrong under the hood.

What happened? I made these hires wearing rose-tinted glasses; for example, weighting tenure too much, and cautionary input too little. While looking good as a flexible team-player, I made a massive problem for my area and our customers.

If I had a time machine, I would have been 100x more picky regarding hiring leaders, critically-checked references, and applied a probationary period with direct instruction.

Confession 5: Key initiative progressed backwards

If you really want to upset stakeholders, show them negative progress on their project.

One of my main initiatives continually increased in scope, with engineers repeatedly discovering more work as they went, resulting in the headline progress metric decreasing or jumping around unexpectedly.

This was alarming to senior leadership, and required no end of explanation. In reality, the project was progressing, and the full scope of work was becoming clearer as the application became understood – these are both Good Things, but not so good that they can compensate for confusing the pants off the sponsors. The perception was that it was a ‘bumpy road’, and trust in our area was eroded, despite the significant progress and achievements in reality.

If I had a time machine, I would have first invested in an extensive discovery phase as the first major task in the project. For example, spending an entire quarter on it would not have been unreasonable, considering the project itself lasts 3+ years. For an important but not urgent project, the work proper can wait until we are confident that we understand virtually all the scope. A challenging discovery phase is a harbinger for a far more challenging project execution.

Conclusion

In the tech jungle, Tarzan falls often, learning from his mistakes, and coming back smarter. Painful lessons? Sure. But sometimes the only way to learn is the hard way. The important thing is to brush off the dust, grab onto that vine and keep swinging into the next challenge with no loss of courage or enthusiasm.

These experiences have become part of the toolkit I use to help engineering organisations scale effectively — whether within a company or as a consultant. If your team is navigating growth or change, I’d be happy to connect and share ideas.

With sincere thanks to Jonathan Sandals for his editorial guidance on this article.