3 Work Culture Gotchas

In programming, a gotcha is a valid construct in a system, program or programming language that works as documented but is counter-intuitive and almost invites mistakes because it is both easy to invoke and unexpected or unreasonable in its outcome.

1 - Your Manager Is The Big Boss

I am fortunate to have had some excellent managers as I developed my skills and began learning what it meant to be a practical engineer. From these experiences, I've realised one thing—your relationship with your manager is your career. They should be someone you look up to and build you into a better person. They should be clear in their expectations and verbose regarding feedback.

I am unlucky enough to have had some terrible managers as I was promoted and moved around. These were more "bossy" than "manager-y" and it showed when it came to how well the team functioned.

More recent experiences have left me pondering the question: does being busy make you look like a better manager? My answer: no. Managers who are constantly occupied with "leadership tasks" and disengaged from their teams are often poor leaders. They lack structure, delegation skills, and discipline. A manager who can't carve out time for their team is signalling that their priorities are elsewhere. This can lead to misalignment between the team's goals and individual goals, ultimately hindering the project's success.

A strong team is one where members feel supported and empowered. When managing complex projects, a good manager understands the big picture and delegates tasks effectively. A skilled manager will know how each component of a solution should function and which team members are best suited for specific tasks. Your team should have your back, managers willing to adapt their approach to leverage the strengths of their team is a hallmark of high-performance leadership.

Companies that prioritize short-term goals over long-term team development are missing a crucial opportunity. By investing in their teams, companies can reap the rewards of increased productivity, innovation, and employee satisfaction.

Your team should have your back.

2 - Greenfield Solutions Are The Best

Someone, somewhere, has likely already solved 80% of your problem. This knowledge should have revolutionized the "buy vs. build" debate years ago. Open-source software is ubiquitous, so why do so many teams prematurely abandon the idea of "buying" a solution? Instead of starting from scratch, focus on the missing 20%. Building a small, maintainable solution is often superior to a monolithic, custom-built one.

The teams I've led adopt a funnel approach. We start by questioning the root problem: is there a more efficient way to solve it, or can we adapt an existing solution? If a direct solution isn't available, can we adapt an existing solution with a small, targeted extension? Only as a last resort do we embark on building something entirely new.

Consider a recently encountered scenario: building a complex data transformation pipeline. Instead of reinventing the wheel with a custom transform layer on top of a custom real-time query solution, you could break down the problem into smaller, more manageable parts and leverage a data lake with standard SQL transformations. This approach is often more efficient and maintainable than a custom solution.

Unfortunately, many organizations prioritize ego and complexity over practicality. It's crucial to challenge the status quo and question the "why" behind certain decisions. By adopting a more pragmatic approach, teams can deliver better results, faster.

Things can be elegant and pay the bills simultaneously; there's no need to reinvent the wheel when you can build a unique bike with the same wheels as everyone else. Software is about building on the shoulders of giants, there's no way you're reading this without one of those giants inventing an operating system, another inventing networking, another a content server and so on; but that's not to say that my little blog isn't something I won't show off!

You can build a unique bike with the same wheels as everyone else.

3 - More Senior Means More Ambiguity

Complex problems demand collaborative solutions. As problems grow in complexity, ambiguity often rises. While some ambiguity is inherent, ineffective cultures exacerbate this issue by "tossing problems over the fence" without adequate context or support.

Leadership plays a crucial role in mitigating ambiguity. Experienced managers should provide strategic guidance and context, helping their teams navigate complex challenges. Even new managers can lead effectively by fostering trust and providing clear direction.

The root of the problem lies in a lack of clear communication and alignment. Consider a new team lead tasked with streamlining the software development lifecycle for a critical project. Managers must provide clear expectations, either explicitly through direction or implicitly through trust and constructive feedback on the solution; they cannot hold the team accountable for the outcome if neither of these is done.

Done well, fostering a culture of trust, leaders can empower their teams to overcome challenges and achieve success. In this scenario, ambiguity will lead to breaking the mould and trying something new, rather than a half-produced solution which doesn't align.

Explicit through direction or implicit through trust and constructive feedback.

I've learned these gotchas over many years, a good manager can be a game-changer, and a bad one can be a nightmare. Why reinvent the wheel for your bike when you're revolutionising handlebars? Focus on problems and then find solutions not solutions to immutable problems. And let’s be real, more senior doesn’t always mean more ambiguity it means more contextual intuition. We, as engineers, need clear expectations and solid leadership to navigate the complex world of software development.