I've been building and leading teams of engineers, providing technical and people leadership, for well over 15 years. I'm grateful for a wide range of experience from growing my own small business, to leading organizations in large multi-national companies, to more recently helping an Australian start-up rapidly scale up their software engineering department. I believe in leadership being an exercise in life-long learning. I do not profess to have a certain management style, nor do I have nearly all the answers. I use a combination of self and organizational awareness and past experiences to adapt my management style to suit the needs of the people, the business and the task at hand.
By nature, I'm a driver. Task focussed and results driven, I want to get things done. I've learned though that that's not how everyone operates, and in fact is a counter productive approach when applied too broadly.
Each individual is different. I believe that a great leader takes time to learn what makes each and every individual in their org tick. What's their professional aspirations, what do they enjoy, what do they dread doing day to day, and what are they passionate about at work and outside of work? It's taking the time to learn this, and most importantly to be vulnerable and share the same so that your team gets to know you, that is the foundation of leadership. Different studies frame this in different ways, but at a high level there's four archetypes of social styles at work. The drivers like me, the analyticals who want to know and question every detail, the amiable who are happy to fit in if needed, and the expressives that want to ensure their voice is heard. I modulate my approach to suit where I think each individual sits on the wide spectrum of these dimensions.
Management is fraught with lessons to be learned — some good, some bad, many down right ugly. In my podcast, Paved With Good Intentions, I share what I've learned along the way.
Subscribe to "Paved with Good Intentions" on YouTube.
Apple is a company obsessed with the customer and their experience with purchasing, setting up and using their products. I learned at Apple how this united focus on the customer can be a force multiplier when managing teams. As a manager, much of our time is spent communicating and ensuring alignment. The efficiency by which we can achieving and maintaining that mind-share is one of the simplest measures of success as a manager. I found that leveraging a shared belief in a core principal is particularly effective in this regard. If you can establish guidelines along which your own direction can easily be understood, those same guidelines can allow your direct reports and their teams to make decision with autonomy and alignment to the company mission. For Apple, this is achieved by always ensuring that decisions are made with the user experience in mind. We constantly asked what the user would expect, does what we're doing fit with the users mental model, does this interaction feel intuitive and natural, etc. Instilling these practices as the means to arrive at great decisions leverages your own problem solving skills through the organization.
A principal that I observed at Apple and seek to instill in other companies that I work at is the notion of shared, collective ownership of the product. At Apple, the product is jointly owned by the engineering team that builds it, the human interface team that designs the interface and interactions, and the product marketing team that will take it to market. This combined ownership creates an open discussion between these different functions for arriving at what's best for the customer. What ultimately arrives in the hands of the customer will be a combination of the design language and intent, what we believe the market needs, and what we can build in time. Reaching the best possible outcome within these, and many more, constraints requires equal input and ownership across diverse functions in the business.
To achieve success in a large company, you have to discover and master the force multipliers that help you achieve more than the sum of your parts. At Apple I learned that one of most powerful ways to achieve this is through narrative, story telling and relationship building. I look back on my time at Apple fondly as it was an amazing place where anyone who had an idea that could get people interested in that idea was capable of achieving incredible outcomes. It's that act of getting other people interest in your idea that is crucial to this process, and it's something I strive to impart to those I work with. Telling a story, crafting a narrative that takes the listener — be it your organization, your team, your customers, your investors — through a journey helps make your idea their idea. This builds alignment that can be translated into traction toward progress.
For me personally, learning the importance of saying no is the greatest lessons to take away from my time at Apple. Some of the most amazing projects and products I worked on at Apple never saw the light of day. Despite investing massive amounts of time in designing, workshopping, coding, demoing… sometimes it's better to just say no. To say no to creating something that's not core to the mission of the business. To say no to something that might make sense now but isn't aligned to a longer-term vision. To say no to shipping something that's not ready, or won't be as amazing as we would want it to be. This is an extremely tough lesson to learn for anyone, and harder still to put into practice. It requires constant vigilance of your own inertia versus your perspective. Any measure of progress toward an outcome and the inertia toward the goal should not reduce the perspective needed to continue to question whether you, and your team, are on the right track. “For every yes, there is 1000 no's”.
Amazon Web Services is a polar opposite to Apple in many regards, but one that added to my experience as a leader is their stance on remote teams and geographical boundaries. Apple seeks to consolidate as much of the engineering efforts as possible in Cupertino, CA. If you needed to meet with a team, or work with another engineer then you walked to their office, rode a bike to their building or caught a shuttle bus to their campus. At AWS, it was almost inconceivable to be working on something that didn't involve a team somewhere else in the world. It felt like every meeting was a video conference. This informed my thinking in many ways. Firstly, embracing geographically diverse teams is a wonderful way to access talent and build teams that have a wealth of diversity in their cultures and approaches to solving problems. To realize these benefits, devising and enacting team and leadership structures that provided autonomy within timezones and separation of concerns between timezones and locations is especially important.
Autonomy is a team's ability to deliver an outcome either entirely within themselves through deep integration of skillsets, or through close collaboration with neighboring teams that allows for rapid iteration. Technology has alleviated the communication barriers that distance would otherwise present, however this alone doesn't solve for efficiency, accountability and cohesion. Those qualities require considered action and reinforcement from the leadership team. The amount of inter-team dependency in any company will depend heavily on the product suite. Is it one product built by many teams collectively, or many products built by siloed teams, or somewhere in between? Working backward from the product helps to guide the structural planning for an engineering organization. I believe the best outcome is to create teams that have the highest degree of self-contained autonomy, or at least clear ownership of a particular product or feature that is a value driver for the business. Aligning to the value drivers, clearly assigning ownership and accountability for those outcomes, and setting up objective ways to measure performance will create an on-going evolution of a learning organization. That is, an organization that is clear as to why it exists, is able to make progress toward that goal with maximum efficiency, and exhibits the self-awareness and vulnerability to accept and enact on-going structural change.
The definition of 12 succinctly articulated, and deeply ingrained leadership principals is the most powerful and unique aspect of the Amazon culture. Every company I've worked for had some degree of a mission and vision. For Apple, these don't need to be written anywhere, everyone just knows it to their core. At Cisco we carried them around on the back of our badges… and sometimes read them. At AWS, those leadership principals are front and center of every meaningful discussion, debate and decision making process from hiring, architecture, coding, performance management and beyond. I was awestruck at the wisdom contained in these principals and the way that these principals allow for autonomous decision making that's inherently aligned to the companies mission. Defining core principals and tenets is an incredibly powerful and important exercise for startups that are beginning to scale and rapidly innovate. These principals need to be defined early, and challenged readily, to ensure they truly represent the way in which the business wants to conduct itself. The result of this iterative process is an articulation of the culture — the values and immutable beliefs — of the organization.
An insight I took from time at CBA is the importance of subtractive leadership: The higher you are on the org chart, the more you need to focus on identifying and systematically removing the obstacles and friction that are holding teams back. This is especially true when an organisation is pivoting from a top-down, project-based way of working toward a bottom-up, product-focussed culture. When leadership focuses on removing the obstacles and helping teams reclaim lost time and effort, then the teams can determine how to re-invest that time and that fosters a sense of investing in their own future. This is the fundamental enabler of bottom-up, team-driven innovation that is essential in a technology organisation.
When I took up the Distinguished Engineer role for the retail bank, CBA was just beginning its transformation into an agile, software engineering organisation. I met regularly with the CEO and Executive Leadership team to provide education around software engineering concepts including APIs, microservices, cloud infrastructure, quality and devops — and, most importantly, how these concept could be applied at CBA as well as what obstacles would prevent that. Across the 2,800 person Digital Technology organisation, I worked with teams directly and in regular office-hours sessions to coach them through adoption of modern event-based, micro services and API principles.
A CTO recently asked me how to convince their CPO and CEO to prioritise paying down technical debt. My answer was to stop calling it that. "Technical debt" is one of the most counterproductive metaphors in our industry, not because the underlying problems aren't real, but because the term itself is actively working against you in every conversation where it matters most. Read more
Getting started as a software developer requires some research before you can do much, but learning through solving problems will help you become productive and proficient faster...
Rapidly evolving paradigms, languages and technologies create in an innate desire to rewrite old code. Outside of very specific circumstances, the urge to rewrite rather than incrementally improve is an anti-pattern that slows down the pace of delivery and puts the business at risk from subtle logic lost in a rewrite.
The relentless pursuit of simplicity is the discipline to avoid initiatives that are not core to the mission of your business, the dedication to abstract away all complexity from the customer in achieving that mission, and continually divesting all activities that are not central to how you provide value to your customers.
Leveraging a mental models allows us to build software that surprises and delights the user by avoiding the trap of functional yet frustrating software.
We make difficult conversations unnecessarily worse for all parties by delaying, procrastinating and ruminating. Don't delay, but do prepare enough so that you can confidently own the message you're conveying. Remember that everyone in the room is human, and after the meeting follow up to ensure clarity and progress toward the outcome you seek. If handled well, trust will be forged between both parties.
Social Style and similar typologies give you a framework for understanding the personality archetypes that exist in the workplace. From this framework you can strengthen your ability to manage to different styles as well as how to your own style to suit a given situation. Learning about social styles raises awareness of the leadership weaknesses that are apparent in your style.
In Crucial Conversations, the authors introduce the Agree, Build and Compare framework for guiding conversations towards agreement. These are the three modes we can assume as we prepare to respond to someone in a conversation. You agree when something is said that you truly agree with, you build upon statements you agree with but feel the need to add more detail to, and you compare between your view and the other persons view when you disagree.
Structuring an organizing with teams that are assigned ownership of value-drivers (products, features, services), and individuals that are appointed as directly responsible for specific outcomes sets up the foundation for self-organization, empowerment and autonomy. Ownership and accountability are related but crucially different.
Hand-writing your daily, weekly or ad-hoc todo lists introduces a surprisingly effective physical tax that prevents that list growing beyond what is achievable. Two years ago, I switched to hand-writing my daily to-do list and I find it to be one of the most important foundations to keeping me on track and helping to maintain a sense of reality about when I can commit to getting things done. Prior to that I had used countless to-do apps, and before then was trapped in the inbox-as-a-todo-list fallacy.
When I write, I start by defining the single purpose of the document and then I'll write just a few sentences that capture the key points I want to make in the introduction and the three or four supporting paragraphs. These few sentences are encased in square brackets and become the blocked-out structure of the document. Scroll down to see the blocks I used when writing this document. With this framework established, I then write the paragraphs that expand on the blocks one paragraph at a time.
Writing to a fixed-length is an exercise that benefits the author by forcing you to distill your thinking down to the essence of the idea you want to convey. Through this process you become clearer and more confident in your own thinking. The result is a document that is crystal clear, that will be easy for the reader to grasp, and that you can leverage to gain traction for your idea.
