This transcript has been edited for clarity and checked against the available source transcript and recording. Filler, false starts, and obvious transcription errors have been corrected without changing the speaker’s meaning.
Brendan: Engineering is, and probably always will be, highly collaborative. Developing the ability to see a problem from different viewpoints is enormously valuable for unlocking collaboration within teams.
A Day in the Life#
James: What does a day or week in your life look like, Brendan? Do you spend all day in meetings, or do you still do much programming?
Brendan: I attend a fair number of meetings, but I’m careful to defend my time. One trick you learn early is defensive calendaring: blocking out and protecting time so people can’t simply invade your calendar. Creating space for deep thinking is important. I use much of it to read and approve internal proposals, as well as some external material.
In meetings, I deal with many aspects of running a large company. Much of it is context-sharing. I maintain a necessarily broad view of what hundreds of teams are doing. Through conversations, I can spot opportunities for team A to talk to team B because they’re doing related work.
Teams may feel that they lack the resources to execute their goals, that their work isn’t prioritised, or that they’re blocked. I can provide context around priorities and help unblock them. That tactical work is important, but I also focus on strategic questions for Canva. The company has grown exponentially, doubling the organisation every year for at least seven years, which creates many scaling challenges.
We must continually evolve our processes and structures, identify what works and where the gaps are, and pragmatically introduce changes as we grow. We also need to look ahead: where must we be in one or five years, and how can we lay tracks in those directions?
I spend considerable time on escalations. When a proposal attracts competing views, it may come to me for a final decision. I handle salary, equity, hiring-plan and tooling-spend approvals, and spend time recruiting. When we’re pursuing top talent, I help sell high-profile candidates on the joys of working at Canva and the challenges before us.
Performance management is another major responsibility: developing and interpreting our career framework so managers understand how to set expectations. We have a promotion system, although at Canva we call them role changes. At regular intervals, we accept applications and assess evidence of an individual’s output to determine whether it meets the required level. We invest substantial effort in calibrating decisions fairly across the organisation. It’s a great deal of work.
Designing a Promotion Structure#
James: When designing structures such as the promotion system for a rapidly growing engineering organisation, do you borrow from similar companies or work from first principles?
Brendan: We do both. We study companies ahead of us on the growth curve and examine them soberly, treating some as cautionary tales and others as examples we may want to replicate.
We always put our own spin on processes and structures. We invest significant effort in understanding what worked elsewhere, then distil it into language that feels familiar and uniquely Canva.
Did Brendan always want to be in management#
James: You now oversee many engineering teams. Did you always want to lead engineers, or is that a more recent interest?
Brendan: It was never a career ambition. I’ve enjoyed both individual contribution and engineering management, but spent most of my career as an engineer building things, with occasional management stints. The difference at Canva is that I joined very early, so my commitment is probably higher than at any other point in my career.
I’ve always believed in doing whatever is needed, as did many early employees. As we grew, the need for engineering management alongside individual contribution became increasingly apparent, and I gradually stepped further into that role.
I enjoy it. Its challenges and rewards are different, but still intellectual. It isn’t coding, although I do that very occasionally. Returning to the tools is always sobering: “It’s been a while—how does Git work?”
James: It’s interesting to hear that path. Some senior people decide very early to pursue leadership completely, while others arrive there differently.
Measuring engineering teams#
James: How do you measure an engineering team’s performance? Metrics such as lines of code don’t necessarily reflect the real work.
Brendan: It’s difficult. The ultimate measure is whether teams set good goals, break them into milestones and deliver those milestones on time. We examine the output of teams and individuals, but don’t want it to come at a personal cost. We call this sustainable urgency: teams should move quickly while maintaining work–life balance and a healthy long-term culture.
Development metrics can be dangerous. We often discuss Goodhart’s law at Canva. We strive to be data-driven while remembering that once a measure becomes a target, it tends to lose its value as a measure. Total focus on metrics also encourages you to prioritise what is easy to measure, although many important things aren’t. Success therefore means sustainable delivery: a track record of delivery alongside the team’s health and wellbeing.
I’ve seen commit leaderboards drive perverse behaviour. People learn to create more commits or divide changes into smaller ones to climb the leaderboard. Code-oriented metrics also imply that other essential activities are less important. Engineering managers set team expectations, run team cadences, and discuss and review technical approaches, all of which are harder to measure. Focusing on hard code metrics can diminish that vital work, which is dangerous.
James: Sustainable urgency is a great way to describe it.
What makes an effective manager#
James: What traits make an effective engineering manager?
Brendan: Our best frontline managers tend to have recent experience on the tools. They’ve recently moved from individual contribution into engineering management, which gives them empathy for the engineers they manage.
We expect managers to contribute technically, usually by giving direction and reviewing technical designs. Direct coding is possible but exceptional because managers are time-poor. The lesson also works in reverse: even somebody on our individual-contributor “build” track benefits from spending time as a manager. It’s easy for an individual contributor wearing headphones to dismiss the pointy-headed boss. Sitting in the pilot’s seat gives you an appreciation for the pressures and intellectual challenges managers face, making you a more rounded contributor. Canva deliberately allows people to move back and forth between tracks.
Managers need technical competence and organisational skills: understanding a larger goal, dividing it into milestones and tasks, and guiding a team through execution. Finally, they must set clear expectations, communicate them explicitly and hold teams and individuals accountable. Those frank conversations can feel uncomfortable to engineers, but they’re learnable skills.
James: Is that something you had to learn?
Brendan: Absolutely. First-time engineering managers often rely on “leading by example”, but that has real limitations. “Do as I do” only works to an extent and can become an anti-pattern, particularly when a former individual contributor simply does a large amount of work without making the intended example clear.
You must move beyond implicitly setting expectations through hard work. Explicitly discuss the role, its tasks and what you expect. That clarity gives direct reports psychological safety. Understanding what’s expected is half the battle in meeting a role’s performance requirements.
10x engineers#
James: Psychological safety helps people feel comfortable thinking and speaking openly. Moving from management to individual contributors, have you encountered “10x engineers” who contribute ten times more than a standard engineer? What do they do differently?
Brendan: I believe the phrase originated in an IBM research project, perhaps in the 1980s. Individuals’ output varies widely, and occasionally an engineer produces an order of magnitude more than a competent colleague.
That can be extremely difficult to manage and create unhealthy dynamics. An individual racing ahead can destabilise the team by producing more work than everyone else can comprehend, review, build upon or maintain.
Work backs up behind them because they’re the only person who understands the system they largely built, which can become toxic. At Canva, we consider that a pathology. We value high-output individual contributors who uplift those around them and take teams along for the journey.
They’re brilliant contributors who also mentor, educate, direct and quickly unblock others. They’re worth their weight in gold because technical communication and teaching lift the team’s execution. We select and reward them rather than the headphone-wearing engineer who only produces code, which is difficult for a team to sustain.
James: You want somebody who raises the team rather than racing alone in one direction.
Brendan: Exactly. Our individual-contributor career track explicitly expects people at higher levels to spend increasingly more time sharing knowledge and acting as force multipliers, rather than simply producing code.
Skill improvement as an IC#
James: There is plenty of education for beginners, but a senior engineer can’t simply take a course and become a specialist who advances the field. How should an individual contributor continue developing at that level?
Brendan: It depends on your learning style. I learn by doing. A textbook remains theoretical until I get my hands dirty with the technology, although others absorb theory and then apply it.
There are no shortcuts to becoming an industry expert. You must invest hours and hours of practice, and it helps to love the work and draw energy from it.
Individual contributors should also vary their problem spaces. We interview people with senior titles and five or seven years’ experience who have actually solved the same problem repeatedly.
They haven’t broadened their technical thinking or built genuine depth because their comfort zone never challenged them. The keys are varying problem domains, finding opportunities to go deep, and investing the hours. Hopefully, you love doing the work.
James: At the top of almost any field, you’d be surprised to find somebody who doesn’t genuinely love what they do.
Tips for Junior Engineers#
James: What mistakes have you seen eager junior engineers make that prevent them progressing as far as they could?
Brendan: The biggest mistake is failing to learn from first principles and focusing too much on technology. They arrive having learnt an exciting tool and immediately want to apply it.
There’s a shiny-bubble effect: “I’ve learnt React, so I want to build everything in React.” We teach graduate engineers to build context, deeply understand the systems they’re building upon, break that understanding into first principles and reason from them.
Test your proposal carefully and apply second-order thinking instead of assuming that knowing tool X makes it right for a problem. Break down the problem, understand the system, build domain knowledge and rationally choose the best solution.
It’s difficult because people want to code and build. Unconstrained ideation—continually asking “What if we did this?”—can become an engineering anti-pattern.
My response is, “You tell me what would happen.” Work it out rather than burdening senior engineers with questions you can reason through yourself. Demonstrating contextual understanding and disciplined thinking is valuable to your team.
Every few years, a technology is presented as a silver bullet by industry thought leaders—or vendors masquerading as thought leaders.
Graduates can become enamoured and worship at the altar of technology rather than examining its value, comparison with prior art and direct relevance to their problem.
Blockchain, thankfully, seems to be losing some lustre. It’s exciting technology and an excellent intellectual exercise, but its practical applications are limited.
James: It has certainly lost some of the shine it had three or four years ago.
Brendan: I’m not singling out blockchain. Before it came NoSQL, which people rushed into without understanding the trade-offs; before that, XML was going to solve everything. Groupthink around fashionable technologies is dangerous but difficult to resist.
James: How do you distinguish a shiny new tool from a genuine breakthrough worth adopting?
Brendan: It’s difficult because some new ideas prove excellent, and with hindsight you wish you’d adopted them earlier. We create space for engineers to tinker and play with new technologies, but balance that against production risk.
I’m a fan of the boring-technology club. Mature technologies have warts, but those are understood; we know their performance profiles and deficiencies and can engineer around them. Bleeding-edge technology has that name because you bleed when adopting it. Canva therefore sets a high bar and requires a clear rationale showing net benefit.
We avoid unnecessarily expanding our technology surface area. A relatively small set helps engineers move through the organisation because they don’t face enormous technological diversity.
It also lowers day-to-day cognitive cost. Familiar technologies and patterns let engineers encounter different system components and quickly understand how they work.
We want to hear about technologies that could uplift us, but the burden of proof is high and must include the total adoption cost. We aim for a step change rather than forking a solution.
We don’t want an old and new way, but one way—which may become the new one. Otherwise, each fork adds another solution until combinatorial complexity becomes unmanageable and impedes maintenance, evolution and further development.
James: Keeping the technology set small so engineers can move around more easily is a valuable principle.
Specialise vs Generalise#
James: What do you advise people at different career stages about specialising versus generalising?
Brendan: We like engineers to specialise, but subscribe to the idea of a T-shaped engineer. They may spend years honing their craft and developing deep knowledge in one speciality while also learning adjacent technologies and skills. The horizontal bar is broad knowledge; the vertical bar is depth in one or two specialities. During a 30-year career, you may go deep in several.
Depth requires substantial execution and time, so choose carefully. I wouldn’t necessarily choose fashionable technology; favour something stable with evidence of execution and success.
I’d be worried about pursuing a degree in blockchain because I’m unsure how applicable it will be.
James: You need to avoid specialising in a trend rather than something with longevity.
Brendan: Choose fundamental technologies and observe where the industry is heading. The stacks used by Canva, Google and Facebook are probably built for the long haul.
Some are boring. We love Java; it isn’t fashionable, but most of our back ends use it, and it remains a good language in which to gain a grounding.
James: That’s an interesting way to think about it. I appreciate your insight.
Engineering traits that are undervalued#
James: Which traits do you value in engineers that the market tends to underappreciate?
Brendan: Critical thinking is undervalued. Many graduates arrive focused on technology and excited by their technical knowledge, but I want to see that knowledge applied critically. Real engineering is problem-solving.
Developing problem-solving, first-principles reasoning, higher-order thinking and an understanding of logical fallacies is extremely valuable.
Empathy is another important, underrated engineering skill. People often imagine a warm, fuzzy, innate emotional trait, but it’s a skill you can hone: seeing the world from others’ perspectives and deeply understanding them. Engineering is, and probably always will be, highly collaborative. Viewing a problem from different perspectives unlocks team collaboration.
One practical technique I champion among young engineers is the unfortunately named “steel-manning”, the opposite of straw-manning. Straw-manning treats a discussion as an argument to win, reduces somebody’s position to an inferior form, then demolishes it. Steel-manning recognises a technical discussion as people bringing diverse perspectives into collaborative problem-solving.
Step back, understand another position deeply enough to argue it yourself, and do so genuinely. You may change your mind or convince yourself of their view, which can unblock a team divided over a solution. Even if you still believe you’re right, demonstrating empathy disarms conflict and creates a constructive environment for progress.
James: It’s far better to work with somebody who understands your thinking and responds constructively than somebody determined to shoot it down.
Importance of startup journey#
James: After several software jobs, you co-founded Cenqua. How formative was building a product and company yourself?
Brendan: Extremely formative. Owning a company removes the safety net. With only four people and plenty of non-coding work, you appreciate every aspect of running a business, not only engineering.
The personal commitment is enormous because nobody else will do the work. We were very driven, although we called ourselves a lifestyle company and told ourselves we could take time off and move leisurely. In reality, you live and breathe the company. That can also be a trap, so you must be careful. It opened my eyes to every aspect of software delivery, not just writing code.
James: Which parts of that journey remain most useful today?
Brendan: It taught me what ownership and having skin in the game mean. In any organisation, the bystander effect makes people assume somebody else will act or decide. Owning a company without a safety net gives you agency: if you don’t handle something, nobody will.
Carrying that agency into small or large companies is powerful. Take complete ownership of a system, component, process, structural decision or anything else, then drive it to completion.
James: That extreme ownership matters at every level. For early-career people who aspire to become a CTO or head of engineering, is there common career advice they should ignore?
Brendan: I can only describe my philosophy. I’ve worked at companies with technology at their centre and stayed as technical as possible for as long as possible to build deep expertise. I didn’t have a destination in mind; I simply did what I enjoyed and have been fortunate in where I landed.
Staying technical exposed me to diverse team cultures, problem domains and solutions. That depth provides a strong foundation if you later choose engineering management. I also have friends who remain individual contributors after 25 or 30 years, which is equally valid. This worked for me, although survivor bias applies.
Failure that ended up being a success#
James: Has something in your career felt like a failure at the time but ultimately worked out well?
Brendan: I graduated in 1997 as the first tech bubble formed. Before Google existed, I wrote an honours thesis on distributed web indexing. I still regret not seizing that opportunity, moving to Silicon Valley and participating as the dot-com bubble formed. Many companies crashed, but others such as Google became household names.
Looking back, I would have pushed beyond my comfort zone. I had relatively unique knowledge of distributed web indexing, then a novel and important subject, but chose a safer engineering job at a telecommunications company. Perhaps I should have tried my luck in Silicon Valley. I don’t have many regrets, however, because things worked out well.
Best investment of time or money#
James: What investment of time or money was crucial to your engineering career?
Brendan: I’ve always enjoyed building software on the side. It isn’t a chore to broaden my skills but a passion; I enjoy tinkering with software and hardware.
That has been enormously valuable. Cenqua earned its first income from one of my side projects, which we turned into a commercial product. I try—perhaps excessively—to develop the discipline to see projects through to completion.
Starting side projects is easy; bringing them to a logical conclusion is harder. I fail more often than not and have hundreds that barely progressed, but I continue trying.
Not everybody has that opportunity; personal circumstances may make it difficult. Side projects and open-source contributions aren’t prerequisites for graduates or engineers joining us. They’re welcome but not expected.
James: Many stories begin with somebody’s side project becoming something impressive.
Advice for Graduates#
James: What advice would you give a recent graduate who wants to become a great engineer?
Brendan: Join a mature engineering organisation where you can learn from exceptional people. Seek teams with strong engineering cultures and formal or informal mentors who can teach you the craft of software engineering.
We deliberately created that culture at Canva, and large companies such as Google, Amazon, Microsoft and Apple also have it. Joining a smaller organisation isn’t necessarily wrong, but graduates can quickly become the most knowledgeable person in the room, which is risky. I believe it’s better to begin somewhere with mentors who show you what excellence looks like and help you reach it.
James: Join a company like Canva. Thanks for coming on the show, Brendan. Where can listeners learn more about you or connect?
Brendan: I’m @brendanh on Twitter, although I tweet very infrequently. I’m also on LinkedIn. I receive many requests, so I may not reply.
James: Fantastic. Thanks so much for coming on the show.
Brendan: No worries, James. I’ve enjoyed the chat.
Outro#
James: Thanks for listening to this episode. I hope you enjoyed it as much as I did. To receive my takeaways and everything I learnt, subscribe to Graduate Theory at GraduateTheory.com/subscribe. You’ll get my takeaways and information about each episode straight in your inbox.
Thanks again for listening. I look forward to seeing you next week.