I’m Leaving Vancouver

I arrived in Vancouver in late summer of 1995, to come to university. I knew, almost the moment I got off the plane, that this would be home from now on. And until tomorrow, I’ve held to that. And let’s be clear – I love Vancouver. I’ve had the great fortune to travel extensively, and have had several opportunities to choose to go somewhere else – and I keep choosing here.

But that’s changed now – I’m leaving. The reasons are multiple, but the short answer to the unasked why is the same as it is for everything these days: because COVID-19. Since the pandemic hit, I no longer need to go to the office, and people, this is a good thing in my books. Since the pandemic hit, I no longer go to restaurants, or clubs, or concerts, or movies, or anything that feels like it requires a city to do.

The other thing that happened is I kind of reconnected with nature. Early on, I made an effort to get to the forest nearly every day: Pacific Spirit park, Stanley park, all over the North Shore and places beyond. And when it got warmer, I spent more time on and by the water. And all the time spent there really centred me – I found a peace that the focus on day-to-day life in the city that I had forgotten about.

In July, right as restrictions eased, we stayed in a place on the Sunshine Coast, in Secret Cove. And while there, thinking about the perfection of it, the slowness of it, we asked each other – “what if we just lived here?” And so about 6 weeks later we had an accepted offer on a house in Gibsons, had successfully sold our townhouse in Vancouver and in about 12 hours, we’ll be moving in.

This – this is the awkward part to say out loud, but for the most part, the pandemic has been good for me and my family: my work is solid (but busy!) and interesting, we’re spending more time together, we’ve saved money compared to our before-times lifestyle. And this move kind of doubles-down on that idea: we’re buying ourselves more financial freedom, more time together, more access to the things we like to do together: hike, camp, paddle, play games – hang out.

There’s things I’ll miss about Vancouver – and we’ll certainly be tied pretty closely as Leah will be coming back weekly, and I hope to be coming back about monthly for various things. One reason we chose Gibsons is that while it is away, it’s not so far away.

The house we’ve bought has plenty of space indoors and out for safely distanced socializing; and when things settle out in a couple of years, there will even be a ready stand-alone guest suite for people coming out way.

It’s funny – for most of my life, I’ve dreamed only of living in ever-bigger cities. I love the bustle of a crowded subway, milling pedestrians – the vitality of a busy city is amazing. Maybe again in the future I’ll want that but for now? I really feel like I like my city like I like my snow: close enough to get to it easily when I want it, but not all around me all winter long.

Peaceful Games in Turbulent Times

Screenshot from Cities Skylines

For much of my life, I’ve used video games as a sort of “social separation mental health strategy” – when the world gets to be too much, I play video games with an intense focus: to help calm and center my mind, to let my subconscious process, to give me a chance to process emotions I’m not handling well. The general driver is anxiety and the need to keeps my hands busy but my mind calm. This is one of the reasons that I often look with bafflement at all the online games: why on earth would I want to play games with others? I play games because other people are too much!

On my iPhone, I keep exactly 3 games: Threes, Alto’s Adventure & Monument Valley. These three games satisfy key criteria for me:

  1. They are low-stakes: there’s no death or violence, and you can just pick back up and go. In Threes, if you fail, just start over, Alto’s Adventure, just start snowboarding again, in Monument valley just try the puzzle again.
  2. They’re quick-plays: it is easy to drop in and play for 5 minutes and hop out again, with no deeper context of story or complicated muscle-memory mechanisms.
  3. they are visually quiet games: there’s not flashy things popping up with adrenaline-inducing urgency, everything is pretty calm, with in all cases, pleasing-to-my-eye visuals.

I should note here that Threes has a particular place for me: I probably spend 10 times as much time in that game than anything else – indeed it is sort of a meditative ritual for me: if I’m feeling particularly anxious, or have an upcoming stressful encounter, or am needing to quickly centre myself after a stress-inducing event, I play Threes – dark mode, sound off. And as I play, I can zero-in my focus until all else disappears except the game board. And then I’m ready to re-engage with the world.

Tangent on COVID-19

I’m fortunate, in this time of COVID-19, to be gainfully employed. Working for Telus Digital, on the platform team, which includes support and oversight of the infrastructure for telus.com means that we are really, really busy. I’m doubly fortunate to have space at home to work well, to have kids who’re slightly older and more independent so I can focus, and that Leah and I genuinely enjoy being together all the time.

But, and probably this a big BUT – I’m constantly fielding a low-level of panic/anxiety/terror. First: I deeply suspect that the world I’ve known for 40 years has ended, and we’re seeing the rapid birth of a new world – where this sort of rotating shutdown/collapse of public society is the new normal, where variations of COVID-19 are like the flu, or colds: new variations coming regularly. And like – everything has to change to make this part of how we live. I hope I’m wrong.

Second: I am personally very worried about my ability to survive COVID-19 – I have a long history of being hit pretty hard by respiratory illnesses: Pneumonia, bronchitis, flu – anything that settles & impacts the lungs has for most of my life hit me unusually hard compared to those around me. I’m generally healthy yes. I’m taking precautions, yes – but my assumption is that everyone will at some point grapple with COVID-19 over the next year or two. I hope I experience a mild case, but until this happens, I remain wary and worried.

And on the Xbox

There’s one more game that I’m spending an additional amount of time with right now: Cities Skylines, a city-building game. I have turned all the “disaster” settings way down. And so it becomes this lovely, peaceful, slow-moving game where I build a town full of happy, employed, healthy people. They bicycle and walk and take transit everywhere. They live in dense, urban centres, or farming communities. Sometimes, I just turn the speed setting to medium and just kind of watch it for a while. And it is immensely satisfying – another low-stakes, low-context, drop-in/drop-out game to calm my nerves, to help me context-switch from work-mode to home-mode.

The Four Jedi (software architects) You Meet in Heaven

Millenium Falcon at Galaxy's Edge

*with apologies to Mitch Albom, of course. We recently got Disney+, and I finished watching The Mandalorian, and then, casting about for what else there is worthwhile, dove headlong into The Clone Wars animated series. It’s great! And somewhere deep in my subconscious, this analogy emerged.

After writing about the paths to Senior Developer, I’ve been thinking about what comes after that. Specifically about what comes after that at TELUS Digital, because that’s where I’m working. Important caveat here:
these are my musings, and not official TELUS Digital policy.
It should also be noted that the types of technical roles quickly bifurcate over and over like a career river-delta if you survey the industry: tech leads, team leads, staff engineer, fellows, principals, architects, managers, etc, so as you talk about more senior technical roles, there’s a higher-chance that you’re being very specific to your current organization. I asked on twitter about one facet of this too, as I thought about tech leads vs architects.

That I ask this question probably reveals a fair amount of how things work at TELUS Digital. But this also made me thing very specifically about the delta in those roles here, as I see it. I’ll talk about the tech lead role another time, but want to think about Software Architects, and the kinds of skills, focus and interests that make for good candidates.

Anakin Skywalker: The Solution Architect

Anakin Skywalker is confident, quick thinking – surging headlong into trouble and thinking creatively on his feet to find a solution to the problem in front of him. This is the kind of architect I’m the most comfortable speaking about because it is how I self-identified when doing this kind of work. It is a broad rather than deep role – a good solution architect can think creatively, laterally about a problem and propose a variety of potential outcomes to solve it. I’ve seen this role advertised many places as a web architect as well. If you’re a developer who loves the challenge of working in an unknown space, who prefers prototyping to refactoring or incremental improvements, this is a great fit. A solution architect has an obligation to keep current on shifting trends – be knowledgeable across a varied set of technologies, frameworks, languages, etc. More importantly than what you do know is a deep understanding of what you don’t know. A good solution architect will know to bring in other expert voices to stress-test and verify an idea. Because of this need, solution architects need to have pretty solid social skills as well to succeed, and should work more closely with developers on a day-to-day basis than others.

Of note: if you know the story of Star Wars, you’ll know that things do not end well for Anakin Skywalker, who falls to the dark side and becomes a force for evil. While this may be really stretching this metaphor, this is a useful thing for solution architects to think about too – too often we hear of Ivory Tower, or “architecture astronaut” if you don’t stay connected to the work happening.

Mace Windu: The Domain Architect

Mace Windu is a master of lightsaber combat, wise and careful of words, thinking deeply about the practice of his craft. He is a specialist, through and through. Domain Architecture is a path for deep specialization and knowledge. This is also variously called a practice lead. This is a good role to think long and deeply about a particular topic to develop unparalleled expertise in it. Spending time learning from, and talking to other experts in your domain is important in this role, to ensure that you do not end up so specialized in your particular company’s needs as to lose relevance. A key duty of this architect role is to impart knowledge to the people around you – both technical and non. More so than a solution architect, ensuring that there is a succession plan – that there is a clear apprentice to follow on is a good practice. Some examples of domains of specialization: Network Security, Testing, Telemetry, Performance, Data, etc. This role is still one of software, and so spending time writing, refining best-practice examples; pushing the state-of-the-art forwards are key outputs from a domain architect. Leading development of mission-critical implementations within your domain is also an important role for this kind of architect.

Obi-Wan Kenobi: The Integration Architect

Obi-Wan Kenobi always saw the underlying truth of a scenario as a way to find the way through it – never hurried, always already where others were going to. He understood, holistically, what was happening around him. This is a role for understanding what lays beneath: how different tools, architectures, endpoints, etc work together. It demands an incredible ability to keep hugely complicated systems in mind and be able to anticipate side-effects and unexpected outcomes from new additions. I’ve only encountered this type of architect at very large companies that have very complex, often legacy systems – a smaller scale operation is unlikely to require this kind of specialization. Interestingly, I’ve met several excellent integration architects who came into this from a business or system analyst role, as well as from a developer role. Integration architects, in my experience, make and maintain the best diagrams, are excellent teachers to others, and unparalleled in their ability to reduce complexity into more digestible chunks. If you’re a developer who likes working on edge-cases, who likes to find the weird exception to every rule, or who likes to think holistically about an entire system, this is an excellent role. It is very much a role of incremental operation of a whole system, rather than rapid prototyping or deep dives. It’s a great place to iterate on a particular system for a long time. If you want to have impact at scale through small incremental change, this is exactly that type of role.

Yoda: Principal Architect

Yoda guides the entire Jedi council with a clear vision of what a Jedi can be, should be, and helping everyone stay on the path to that vision. Including a Principal Architect may seem something of a cheat, in that I would consider this an additional tier of seniority than others – certainly at where I work now it is – but it isn’t always. Sometimes, it is the only architect. And this is largely a visionary role, to look forwards towards what might be, what can be, what must be for organizational success. It needs to be an architect who can think broadly about the range of opportunities to improve technology, who can work with other leadership to translate technological vision into business relevance. At some places, this role may well simply be the Chief Technology Officer (CTO). At somewhere large enough, there may be multiple principal architects, spread across the vast swathes of organizational complexity. A key duty of this role is to help support all the other architects as well – to provide support for their decisions, to provide rigour in decision-making, to ensure that everything roles up towards a coherent vision of good.

Do these kinds of role exist where you work? There’s probably all sorts of variants of this. For TELUS in particular, the software architect path is generally for people who want to stay primarily as individual contributors, rather than leads/managers. A path of bits, rather than heartbeats as it were. One thing I wish I had more insight is to what some key differences between something like a staff engineer and a software architect. Do places have both? My instinct is what I’m calling a solution architect may be akin to the staff engineer elsewhere, but YMMV.

Developer Levels: evaluating professional growth

This is one of those things that my instinct with developer levels is “I know an [X] developer when I see one” – but if you’re a developer reporting to me, that’s completely useless. It smacks of subjectivity, of hidden gatekeeping. It would be really hard to argue with me if my position is simply “you’re not it, yet”. And because I currently work with some of the absolute smartest, most skilled developers I’ve ever had the pleasure to work with, I’ve needed to think long and hard about this. Because while they’re all great, they’re not all at the same level of title-seniority. This is also a topic that has been written about many times. I’m focusing here on roles we have at TELUS. For a great wider/larger look at titles, please read @reiver‘s post “Software Engineer Title Ladder
At the same time, internally, we’ve been looking at building out a better career matrix in order to help guide these conversations across all disciplines. We’re still working on them – but with any luck, I’ll be able to share out at least our developer matrix (NB: in Canada, we don’t talk about engineers, but developers. If you’re elsewhere, you may substitute as per your comfort level). So with all those caveats, here’s some ideas I’m working through:

Problem Solving

  • A Junior Entry-Level Developer (I don’t particularly like that term junior – it feels vaguely pejorative – but that is another topic) is someone whom I can hand an identified, solved problem, and they are be able to implement the solution. I expect all asked-for particulars to be included, but I also expect questions to be asked, that the occasional thing might get missed, and that they would not necessarily be able to balance conflicting priorities in code without guidance.
  • An intermediate Developer is someone whom I can hand an identified problem, and they are be able to provide one or more solutions and implement it/them. They are be able to discuss the merits of each solution versus the identified problem’s parameters. I expect good testing habits, and a reasonable attempt to balance multiple concerns during implementation.
  • A Senior Developer is someone who can identify a problem that needs to be solved, include wider concerns when considering solutions and then guide implementation. They are able to help guide other developers when working through ideas, and help shape the work output that results. Senior developers can execute with a very strong understanding of the product lifecycle – so their work can have huge impact on the shape of the code base over all.

All of the above is not linear, and very open to interpretation. You’ll note I don’t talk about particular skills – in part because I’ve been looking for a through-line that would carry across different specialties, but also because my experience mostly tells me that skills and knowledge accumulate as you go. I’ve also several times encountered the inverse problem: deep specialization in one stack or skill leads to blind spots that I find troubling at more senior tiers of work. Either way, these conversations are hugely individualized and hard to generalize. But I think a useful way to put it might be: seniority is a combination of deep knowledge and broad application. Lateral thinking is important, as is deep knowledge and strong skills.


The other key ingredient in developer growth is on the mentorship side: Writing software is a team sport. Mentorship is multi-faceted, and can consist of a variety of things: lessons-learned, code practices, problem-solving skills, organizational-awareness, skills from other disciplines, leadership skills, etc, etc. This can be direct pairing, training opportunities, group work, special projects, etc. Mentorship is itself a program that can either reinforce existing biases or slowly shift them (that link is from 2008! sadly still feels relevant). So being incredibly intentional. both as an organization, and as a people-leader, about what is wanted out of a mentorship program is vital.
I believe that all levels can participate in this, in different ways:

  • An Entry-Level Developer will seek guidance, and share news ideas back into the community. If you’re learning, one of the best ways to learn is to do it publicly (see this very post. This is a lifelong thing). And asking questions demonstrates an important level of humility. And so junior developers looking to grow will proactively seek out opportunities to be mentored, or to surround themselves with senior developers. There’s… there’s a level of privilege associated with this idea that I’m still working through – just being comfortable asking for mentoring. The other side of this is the “new blood” idea: change is constant, and junior developers not set in their ways are amazing at surfacing new ideas, techniques and technologies otherwise dismissed by developers more used to “the way things are”.
  • An Intermediate Developer will share knowledge broadly and seek opportunities to mentor those following in their footsteps. This is the time in a career where confidence is high and more risk-taking has been earned. Be opinionated! But lean on data over opinions. And so writing, sharing internally, leading prototype builds, attending conferences. Because career mobility is very high, aligning resume development with org goals can be mutually beneficial. And in my experience, this is a time where personal ambition and organizational goals can be quite tricky to balance – investing in someone who will leave later is not the goal – but nor should it be deemed a failure. While knowledge at this tier is high, it is still being solidified, dedicated time and practice of mentoring more junior developers can help mature the intermediate developer.
  • A Senior Developer will lead patterns and practices, and stress the details with fellow developers. This may seem counter-intuitive – I’m largely saying intermediate-level should focus on board ideas, while senior developers focus on sweating the details. This is for a good reason: a senior developer will understand a level of nuance in problems that may escape a more junior developer. I often like to say that as a senior developer, the most important ability is to know what you don’t know. But you also may have wider organizational exposure, so leading initiatives in code review practices, testing patterns, performance techniques, etc will have huge impact. Lastly, if a senior developer is not actively mentoring one or more junior developers, they are not contributing enough – but the fault may not be theirs! One thing I’ve seen time and time again is that organizations get in the way of this practice – whether formalized or not – by demanding huge amounts of output from senior-level developers (arguing, perhaps, that they are paid a lot, so should write a lot), and not providing time to grow the rest of the team.

There’s obviously a huge amount that can be, that has been written, on this topic. And, because it is a complex relationship (and it might be another post?), I’m not including Software Architects (and all variants of them – principal or emeritus engineers, etc), who while generally more senior, represent a specialized career track in my opinion, as do engineering leaders (tech leads, managers etc). The question of “what happens next?” when you’re a senior developer is definitely one we struggle with a TELUS, and something I’m thinking a lot about.

One last note: willingness to be wrong is another axis I think is important, where both junior and senior developers are more willing to admit to being wrong than intermediates – and I think this curve is a good sign of growth.

Role Fit

This question comes up a lot in context of the above – what comes next when you’re a senior developer? But this actually a really important conversation to have at all levels. I’m a big believer in the Pioneer / Settler / Town Planner model of types of work (note: that particular phrasing gives me distinct qualms, due to the genocidal history of pioneers & settlers in North America. Bear with me, please), that I believe Simon Wardley coined (at least, his writing was my introduction to it).
People are not all the same, and are not excited by the same types of work. This may seem really obvious, but I have only twice, in 25 years of doing this, come in to a company that didn’t essentially consider all developers to be the same person in some basic way. Maybe distinguish between front- and back-end, or developer and QA roles. Very little is done, in my experience, to help developer self-interrogate as to which kind of work they like to do, and sell all kinds of work as being equally exciting and important (see: unconscious bias).

  • An Entry-Level Developer should be given opportunities to explore various roles: both in style-of-work models, but also in specializations. Early-specialization is as problematic as early-optimization.
  • An Intermediate Developer will develop a sense of their preferred model of work: indeed, this might be the key outcome of this portion of one’s career. Note that having a preferred mode doesn’t exclude others – but it can help inform all sorts of personal career decisions.
  • A Senior Developer will have an understanding of their preferred model of work. Senior developers have experience, knowledge and a level of self-awareness that informs this. Everyone understanding this can help prevent square-peg-round-hole syndrome.

Note: Preferred working models can definitely change, either via personal interest or organizational mandate. But if as a developer, you find yourself struggling to fit in on a new team, reflect on this particular axis of work-modelling. Same for leaders, who’re not seeing the results they were expecting of a newly joined team-member.


I innately reject time-based markers of seniority for engineers, but nor do I want to completely discount them. But time-spent is not spent equally. An organization firing on all cylinders will grow senior developers much faster than one that is in disarray. I’ve also seen developers who’ve got 15-20 years experience who simply have not kept up with changing practices.

So… how do you tell what “level” a developer is? it’s not here yet, but I think but I think there’s a series of variables above that can help define that, but also an individual could easily advance very differently in each category, making these titles feel increasingly inelegant and arbitrary. Mapping these to defined organizational role-titles remains important though, because that how I can talk to my current team, and it directly affects compensation for them.

Reflecting on my own experience, senior developer is still, in the arc of possibility, not even the midpoint of a developer’s potential career progression. And that next transition point remains deeply interesting to me to think about.

Managing through aphorisms

They’re clichés, sure, but are for a reason. And in a sound-byte driven world, having a punchy phrase to summarize what is often full of nuance is useful. I find myself returning to these as mantras, rallying cries and whatnot repeatedly as I lead a team, pull in collaborators and stakeholders, and generally try to make better software in better ways.

Default To Open

In what is probably the most surprising 180 from my early career, I lean deeply on this idea, across several ways:

  • open source your code. This has a few effects: write all your code like someone else is going to read it, that you don’t know. Make sure your code is functional. More basically, thinking in an open-source mind changes some approaches.
  • Talk about your work openly. Learn in the open. Share your learning, your success, your failures. Write about it. talking about. Let anyone who wants to follow along follow along. This helps remove some barriers to being vulnerable in my experience, and can help sharpen thinking by actively, consistently reflecting on work in progress.
  • Give access to your work. Open your backlog for others to see. Keep tickets available to submitters so there’s no back-channel. Talk in open channels not private messages. All of this can help drive a practice of asking questions, being respectful of others’ learning, a safe space for vulnerability, and being kind to clients/stakeholders.

Aim for Less Wrong

At all times, assume you’re wrong. Your goal is to get to be less wrong. You can only validate how wrong you are by talking/sharing with others, and being humble about that. And understand that everyone is wrong at the start, and constantly working to get to less wrong. I’ve found that by repeating this over and over, it can help lead to some changes:

  • asking more questions
  • being kinder in response to “dumb” questions
  • putting something into existence to work on/against, vs being paralyzed by choice to start. It’s easier to talk about something in particular vs a general idea “let’s do X” rather than “we should do something” gives an opportunity to change X.
  • It removes the stigma and potential shame about being wrong – you’re already wrong. Know this, accept this, and aim to be less wrong.

Writing software is a team sport

This is sort of the corollary of go alone to go fast, go together to go further. You need others to be successful, because everyone is full of biases, and other people help you get around them. And people with different skills are required for a good team. I’ve found this is a helpful gentle nudge away from individuals who constantly want to be a hero and take everything on by themselves too.

Write less software

Perhaps ironic for a software team, but the best software is the software you don’t write. Much like how a car loses half its value as you drive it off the lot, All production software is legacy someone needs to deal with in the future. So write less of it. If you can use someone else’s software? if your default position is “I don’t need to write this”, it can really give focus to the decision that, indeed, you do need to write it. Can you justify why you haven’t just used someone else’s software? it is worth the effort, the cost of maintenance?

Write boring software

This goes along with the above. We all want to write super-brilliant, complex software that’s on the cutting edge of everything because we’re that awesome. But guess what. Chances are that you’re only going to be responsible for 10% of that software’s life. OTHER people – OTHER systems will have to be able to work with in in the future. So if you follow common patterns, you lower the cognitive overhead to learn it. and maintain it. Resumé-driven Development should be avoided in almost all instances, because software needs to live in teams, not individual’s heads. It also means to, more often than not, move cautiously. Don’t adopt that rad new framework just because it is there. The larger the organization, the more important this is. Human ability to share immense code-bases because of predictable patterns is major advantage.

Progress is more important than excellence

Everyone wants to be the best. Strive for that. But perfectionism is the enemy of good (is that another aphorism to live by?). What’s important is consistent progress towards better on all plans. experiment, iterate, improve. Fail one time? that’s fine. learn and do it better next time. If you’re the best, if everything is excellent, you’re in the wrong job – because you’re not being challenged. Similarly, if you can no longer progress, you’re in the wrong job – because you either don’t care or you’re in the wrong role for your skills.

There’s of course and endless list of these. These few keep cropping in conversations over the past year or so. Other things I’m trying to find good wording for is around the concept of how good software is living, or like a plant, or something – that you have to maintain it, update it, let it adapt to the world around it, etc.

A year (or so) in


If you recall, when last we left our intrepid hero, he’d started a job at TELUS Digital. It’s now been shortly over a year, so let’s check in, shall we?

[Ed note: I can’t keep that 3rd-person voice up, so abandoning it. But I love the phrase “our intrepid hero”, so the opening stays]

Today, I want to write about parenting. I wrote a post for our corporate blog about my experience as a working dad. And so that’s been on my mind. And then, the other night while out for a post-event drink with a couple of people on my team, I was asked “Do guys talk about the struggle? Juggling parenting and working and gym and shopping and, and, and…?” And I had to think about it a moment – and it’s definitely only my personal experience, but the short answer is “no”, we don’t. I don’t see many examples in pop-culture (TV) or on social-media (outside of dad-blog culture). And it’s not cool, so I’m going to:

It’s hard, y’all. When I was working from home, part time, I had a great life. I got work done, I got to the gym, I saw my kids a lot, I got out with friends. I didn’t cook too much, because I don’t enjoy that much, but I felt on top of it all.

Since coming back to work full-time, this has changed. In the year prior to coming to TELUS, I was really good about getting to the gym 3 times a week – I lost about 50 lbs in 15 months. In the last year, that’s just stopped. I had to make priority decisions, and it lost: I work, roughly, 9-to-5. I can’t get to the gym in the AM, because to get to work on time, I’d need to be at the 7am class. And I can’t do that, because generally, I do the morning stuff at home – get the kids up, make breakfast, make lunches, etc. There’s a 5pm class – which would mean leaving by 4:15, which is really hard. There’s a 6pm class, but that means I wouldn’t be home before 7:30ish, and I’d miss virtually the entire evening with the kids, not to mention a late dinner time that might run over the 8yo’s bedtime.

I no longer feel like I get enough time with my kids, and I’m not satisfied with how I spend some of what I do. Professionally, I interact with people all day long. I’m in hours of meetings every day, I’m leading people, I’m on. As an introvert, this is draining. I show up and bring it every day, and then I’m just wiped. And I need recovery time, alone in my head, to be able to bring this every day. Indeed, I’ve stopped listening to podcasts, even music with lyrics most days on my way home from work because I just don’t want to hear any more talking directed at me. And, and this sucks for my family, because some days I just don’t have it in me to be as present as I’d like to be for them. There are (many) days I just want to stare off into space to recover a little.

I don’t see my friends as much, in part because of the above. But also because everything else that needs to get done – taking the kids to their activities, shopping, laundry, etc – there’s just so much less time to do it all, and that gets prioritized over beers with a buddy. And I do miss that.

So, yeah. Being honest, I don’t feel I know how to balance work and life in a way that feels “right”. I don’t believe so much in “work-life balance” because by the nature of what I do and how I do it, I need to believe in it, and so I tend to think about work all sorts of strange times and ways, and that’s all good. And this is nothing like how hard it was when it was my company, and all the extra pressures that brings. But I don’t feel like I’ve got it figured out. And I definitely look around in wonder at some colleagues with families and wonder how they manage to do it all. Sometimes I make judge-y assumptions about them, but increasingly, I suspect they’re also struggling, and just making different, invisible compromises to make it work for them.

3 years with an e-bike

My Bike, as I unboxed it.

A little over 3 years ago, I tore my ACL. It wasn’t awesome. I was in constant pain, and worst of all, I couldn’t ride my bike – my primary means of commuting. I decided that an electric bike would help keep me moving and active.

In October 2016, I brought home a VanMoof Electrified S (that link actually goes to the current model, the S2). I was immediately in love with my bike. I think I only rode my former, much-loved MEC Hold Steady (matte-black version) once more before it was sadly stolen in March of this year.

My VanMoof is definitely a v1 device – even the 2017 version of the same bike had some notable improvements. That being said, 3 years in, I’ve come to know it pretty well, and with that in mind, here’s some things I love, and things I don’t.

The Awesome

  • the integrated lights! I don’t know why this wasn’t immediately stolen by all commuter-bike manufacturers, whether electric or not. I have mine set to “Auto”, so they just come on or turn off based on light levels, and I never have to think about bike lights again.
  • Electric-assist: I know, it’s an electric bike, but riding 10-15K a day, with assist that “smooths out the hills” is still revelatory.
  • Quiet. I’ve read that both the 2017 model and S2 are even quieter, but this bike is already much quieter than virtually every other electric bike I come across. There’s a light whisper with the regular e-assist, and a slight whine when I engage the boost feature. Speaking of…
  • Boost! There’s a button on the handlebar to get a boost of extra power beyond the assist level – this is very handy to keep chill on hills, starting up at lights, or when heavily leaden with bags.
  • The design remains distinctive and lovely. I get questions or appreciative comments monthly, even 3 years later.
  • Ride comfort. This is a well-built bike made for a comfortable ride, and is quite smooth.
  • Battery life. I bike 10-15K a day in my commute, and I generally only charge my bike once a week. I think it advertised 100K and 3 years in, I feel I regularly get pretty close to that. Except in wintertime, when the batter is notably worse.

The not-great.

  • The touch interface. Mine has simply never worked reliably enough to use. I’m supposed to be able to touch turn it on, adjust assist levels and what not. I just pretend it isn’t there.
  • The app. It’s pretty bare bones. It loses connection with the bike semi-regularly so I have to force-close and restart it. I wish it integrated with GPS tools like Strava or Runkeeper to pass on information. I’d love to look in my VanMoof app to see total miles, average speed, time spent with what level of assist/boost, etc.
  • The bike software itself. I’ve had my bike “crash” 3 times (about once a year). It takes resetting the software, a process that itself means plugging the bike into a powered micro-usb cable for a bit to reset itself. 3 times in 3 years isn’t a lot, but it does always seem to happen at the end of a long ride when the battery is low, coincidentally right when I’m about to ride up a big hill
  • Speed settings. My bike seems really happy cruising along at about 18-20 km/h. Which is fine, but definitely much slower than a lot of other e-bikes run at. The Boost, for instance, doesn’t work if you’re going more than 20km/h. I find when riding on the flat, once I hit a speed of about 22-24k, the bike feels like it is actively resisting me, rather than assisting me. So, 18k is fine, but often not as fast as I feel I could go without additional effort, but the bike feels like it is fighting me if I do.
  • Weak motor. I joke that my bike is made for Dutch Hills (Holland is famously flat). It really struggles up the bigger hills in town – from false creek up Ontario st is a daily ride for me, and it whines somewhat ominously, and even the boost, while definitely helpful, means I still get a workout up there (maybe this is good?). Compared to a Trek ebike I was able to try out, I’m clearly not getting the same level of push up a hill though.
  • No gears. I don’t want many, but from that one time I did a tour of burrard inlet, biking from home, across the lions’ gate, along and back over the second narrows, having a gear to help me climb hills better, rather than relying on the underwhelming motor would be nice.
  • Cheap/bad parts. VanMoof definitely skimped out on some of these. The stock pedals and cranks look and feel cheap. The brakes have been problematic the whole time – indeed, the first time I took my bike to a shop to get my brakes adjusted, the comment was “Oh, these are really bad – you should replace them soon”. for a $3K bike, that’s not cool.

Other notes

This isn’t so much about the bike, but rather Vancouver – I don’t feel like I can ride this bike and park it anywhere – even with the “smart lock” and tracking technology built-in, Vancouver is so bad for bike theft that unless I know I’ve got secure bike parking or The Bicycle Valet at my destination, I won’t ride anywhere I’d have to leave my bike out of sight.

You may wonder if I’m happy with my bike, based on that list of pros and cons above. In short, the pros vastly outweigh the cons. The bike is amazing, and I’d recommend it to anyone. Particularly the newer models, which all have very directly addressed several of the problems I’ve seen with it.

Everyone should ride a bike more – and if you need some help doing so, I cannot recommend an e-bike enough. And in 2019, your options are much broader as to what’s available, for a surprisingly reasonable amount!

Podcast Radio Station

Radio City Music Hall

One of my favourite CBC shows is Podcast Playlist, which is a weekly, curated show where Matt Galloway & Lindsay Michael sample a set of podcasts, around a particular theme. They play excerpts, or whole episodes depending on length, and talk about why they have included it.

Related, much to my surprise, one of my favourite [ed: counterpoint] developments in media are these post-show discussion shows (Talking Dead, Talks Machina, After the Thrones). I should note that some of these shows are terrible, some are good. The better ones tend to be web, rather than network, and more free-flowing. They’re also all universally too long.

Whether web-based/digital or, my ideal, an honest-to-goodness terrestrial radio station, would combine these into a thrilling, diverse and interesting talk-format discovery station. With programming divided up throughout the day/week, with curated hosts, and re-broadcasting entire podcast episodes, it re-invents the incredibly tired call-in-and-rant structure of current talk radio. It also offers a chance for different new revenue streams for podcast creators (who, in my idea, are of course compensated for all re-broadcasts & take some share of advertising revenue).

Let’s say you divide each day into 4-hr segments, where hour 3 (or maybe just the last 0.5 hr) is the “discussion of what you just heard” segment, ideally including one or more of the podcast creators you were just listening to, and allowing inbound contribution via phone/text/whatever (like any call-in show).

If there were regular, recurring scheduled themes, I’d tune in for topics that interest me. For serial podcasts, like Serial, this offers an opportunity to have a scheduled broadcast over several weeks. Some would be one-offs, and some regulars for weeks or months at a time.

Last-minute thought: In many ways, this is the model CBC Radio 1 already has. Most of the shows are essentially podcasts (Q, Under the Influence, Ideas, Quirks & Quarks, Spark – the lines between regular radio-show and podcast are very blurry) already, intermixed with news/current event shows. The key difference, I think, is an expectation that the station is curating other people’s content, as well as probably producing their own. For a broadcaster like CBC, with a mandate to support Canadian culture, this could be a really interesting new station, pushing out Canadian podcasts to the world.

My 5 Favourite songs about New York City

Cabs near times square

These aren’t “the best”, just ones I like. And I’m pretty-much ignoring hip-hop/soul here, because that is a real void in my musical knowledge. The impetus was listening to the first one, and thinking about other tracks I keep coming back to.

1. Gil Scott-Heron “New York City”

This album was my intro to Gil Scott-Heron. I’m pretty sure I found it amongst my uncle’s album collection as a kid while visiting. It was on a mix-tape I made from his collection, and I played that cassette until a dying Walkman destroyed nearly a decade later.

2. Cub “New York City”

Vancouver’s own Cub. You may know this song from They Might Be Giants’ cover, but this is the original. It is perfect pop-punk.

3. LCD Soundsystem “New York I love you, but you’re bringing me down”

(NB: pretty sure that’s not an official video, but how could you not love it?) This song is also peak LCD Soundsystem.

4. Lou Reed “Walk on the Wild Side”

Could any list about NYC music not contain a Lou Reed song? I probably could have chosen any number by him. But this, while an obvious choice, is the soundtrack of when I think about the New York that was.

5. Leonard Cohen “Chelsea Hotel No. 2”

Like Lou Reed’s track, this is a hymn to what was, only from the singer’s viewpoint, a leisurely look back to days long gone.

Honourable Mention – Ryan Adams “New York, New York”

This song, with the lyric “hell I still love you New York” was ubiquitous in the wake the of September 11th, 2001 (the video was shot apparently just days before). I had to put it down for a while because of that, but I’ve recently been rediscovering Ryan Adams, and this song along with it.

My leadership principles

The path not taken

I’ve evolved my approaches to team-leadership over the years (as to be expected), but I’m not sure I’ve ever sought to explicitly write down a These Things I Hold To Be True. Many of these are fairly office-directed, but most apply to my approach when I’m team captain or kids’ coach too.

While writing this, I realized how much of what I consider to be important leadership activities are not things that come naturally to me, but are rather trained skills that I work at consistently. So please consider this a living document too: I’m always looking to improve both this and myself.

  • A successful leader creates more leaders. Remember you’re standing on the shoulders of giants. You don’t become a leader just because of your skills, but also everyone’s around you. Your teachers, your mentors, your peers, your reports – they all help make you a leader. Respect that continuum and play your part to carry it on.
  • Expect to learn from those you lead. This builds on the first idea, but is more explicit. Just because you’re in charge, doesn’t mean that you’re right, or that you always know better. Ask questions. Be curious. Respect opinions. Corollary is to try to hire people who have something to teach you, whether those are hard or soft skills.
  • Facilitate independence. Don’t be a roadblock for your team. Create structure and process that lets your team explore on their own. Encourage decision-making & independent thought. Provide scaffolding for them to stand on while they work. Be a safety net (or rope-and-harness?) if they fall. Transparent, living documentation of process & procedure is good for all.
  • Do the things that don’t scale. Alternate: sweat the small stuff. Remember birthdays. Remember family names. Ensure the pens work. Have the one-on-ones. Make sure the environment is solid. Clean the white board. Show up a little early to the meeting to make sure there’s water, chairs, whatever. If someone mentions something in an off-hand comment, follow up. Pay attention.
  • Own your team’s failures. When something goes wrong (and it will!), take ownership. Don’t pass blame down the line. Be the shield for your reports. Within your team, don’t point fingers. Post-mortems are your friend. Understand what went wrong, and look for how to prevent that in the future.
  • Let your team own their victories. This is the corollary of the last item. Chances are you’ve had plenty of opportunity to shine on your way up. Step aside, let them accept credit. Better yet, go out of your way to give credit to your team-members publicly for their effort. Related to this: celebrate milestones.
  • Be decisive. You need to be ready to make the call when asked. Or step in when something isn’t working. Do your homework, read up, be ready. Trust your instincts. Remember that *most* decisions are reversible. Be ready to provide a path, a solution, or just an affirmation when needed.
  • Be deliberate. A corollary of the previous point: sometimes, a decision is paradigm-shifting –  *not* reversible. So take the time you need, but be firm and committed to the path chosen.
  • Practice and encourage self-care. Your manner, your tone, your emotional state has an outsized effect on your team. If you want your team to be their best selves, do what you need to be your best self. Demonstrate this so your team knows it is ok when they need to do it.
  • Experience the front-line. Participate in pager duty and answer support calls. Push code. Whatever the most junior among you, or the most publicly-exposed experience, make sure you have a reasonable understanding of their day-to-day.
  • Advocate for the Customer. That customer could be yourself, a client, another department, whatever. Chances are your team is delivering something to someone. Be the voice for the customer internally. Talk to the actual customer. Keep the relationship between your team and the customer healthy.
  • Earn your team’s trust every day. Listen actively. Believe, and believe in your team. Be right. Be focused. Be honest. Be self-critical. Be ethical. Default to openness. Give trust. Support your team-member when they need it.
  • Embrace Constraints. It is almost always worth figuring how to do more with less. Optimize where possible. Lean on limitations to see where they lead you. Create limits and boundaries where they are otherwise unclear in order to provide direction & guidance.
  • Confront your bias. You’re human. You have blindspots. You have biases. Keep these in mind. Build a team that helps you reduce, confront and account for these. Find mentors, peers, advisors to explicitly work on these.
  • Fight Culture-fit. This both seems counter-intuitive and oppositional. But “culture-fit”  is a step on the path to homogeneity. Diversity of people leads to diversity of opinion & thought. It leads to better compromise and outcomes. Culture-fit is not the same as team fit. The former is an ephemeral, subjective judgement of person. The latter is a quantifiable, objective judgement of skill, role, expectation.