My career is filled with failures.
Despite clear evidence to the contrary, computing was my very first career choice. in 1983, at the age of 9, I met my first computer. It was an Apple ][c, which was kept in a special, locked, desk, alongside 11 of its brethren. And I took to it quickly. By the next year, I was learning Logo and playing Oregon Trail and Aztec. A friend of mine's father was an accountant, and had both a 300baud modem and an account on DATAPAC, and we spent a couple of evenings logging into things, trying to figure it out. By high school, I was programming useless little things in Turbo Pascal and Hypercard and had a reseller account with a local wholesaler so I could get cheap hardware. I ran a somewhat popular local BBS and started playing with Linux.
But my first real attempt to be a computer programmer went off the rails quickly. Thinking I was hot shit, I signed up for a computer science program at the local college right out of high school. I didn't even get a chance to fail Calculus I, instead being strongly advised to withdraw from the class (I did). I also flamed out at not one, but two CompSci classes (Modula-2 and VAX/VMS Assembler). It was readily apparent that a Computing Science degree was not for me, and I was beside myself.
I licked my wounds for a couple of years, and took time away from school to work. When I went back, I was sure I wanted to go into archaeology and anthropology. And I did show some aptitude for it (I still follow both classical archaeology and palaeontology). Even in that, however, computing followed me - one class made use of an early virtual archaeology program. But that, too, quickly emerged as something that wasn't in the cards for me (mainly due to some great advice from an archaeology professor about being very, very certain about wanting to enter the field, because "you'll spend three years searching for funding, and 6 weeks in the field"). I pivoted to the perennial university classic, an English degree with a minor in Canadian History.
To help pay my tuition in the mid-90s, I worked for an ISP in Vancouver doing technical support. I had moved from my BBS to the web and IRC; I was part of a great community, and was dabbling with HTML and image editing. It was enough that a friend decided to take a chance on me and hired me as a technical writer. I put together advertising and a user manual for their new company. That led me to do become a web designer for an ISP in Edmonton, who hired me to do much the same work. My friend from earlier had grown his company, and asked me to come back. As an overly confident mid-20s employee, I negotiated a creative director title. I wasn't great at it (sorry Dana), because I rose too quickly. I didn't have the professional maturity to excel in that job, and made quite a few tactical mistakes, mostly around how I interacted with the other folks in my team. It was a moment of growth in my career and in my life. Dana, to his credit, gave me the room to fail. Eventually, it came to an end, and I went back to the trenches as a web developer. But I’d learned a valuable lesson about not being ready to take on a leadership role. I spent the next 15 years slowly building up the skills I needed by working in the trenches, and taking mental notes on what did and did not work in my teams.
All this to say that I've tried a lot of things, and not been great at as many of them as I’d like. But I’m still trying and failing, because I learn something every time. One of my most educational failures came at Online University, when I was managing a federally grant-funded project. I had helped put together the proposal for the project, and had planned on hiring, amongst others, two developers - a senior web developer and a junior web developer for a 12-month period. I would take on a project manager role in the project, so that I could divide my time between it and a few other projects that needed to be executed in my department. The proposal was solid, and we got the funding.
Of course, due to institutional policy, we weren’t able to hire until the funding was secured. Which meant that the clock started ticking on the project without people in place to work on it.
At the time, the local market for web developers was scarce. We had very few applicants, and within those the talent pool was pretty meagre. I had it in my head that I wanted to have a senior and junior start at the same time, so there would be a strong mentoring relationship set up. I didn’t take into account how difficult the hiring process would be, or how long it would take.
It took 6 months.
But, finally, I had two folks in place. True, I wasn’t that keen on the junior developer. I wouldn’t have hired him alone. But it was OK, because I had the senior dev queued up, and she was really good. So good, in fact, that she got a better offer and told me about it the day before she was due to start. She was appropriately apologetic, and had the good grace to call me and tell me the news in person. And, of course, she made the right decision – the position she took was more in line with the direction she wanted to take her career. I couldn’t blame her. But now I had a junior developer that I wasn’t too hot on to begin with as the sole development resource for the project.
I made a bad decision at that point. The project was still salvageable. But only if I stepped in and took on both the project manager and senior web developer role. I could do that – I had the skill and experience to do so – but it meant sacrificing my other core work to do so, setting those other projects back because I couldn’t dedicate my time to them. It turned out that early-30s me was still overly confident in my ability.
Much later, I realized my other bad decision had come much earlier in the process. I’d hired someone I wasn’t confident could do the job, and justified it to myself by pawning the hard work of mentoring them on to someone else (the now missing senior dev). And that had a profound effect on the health of the project. We spent a lot of time spinning our wheels and revisiting functionality because the junior wasn’t up to the task at hand — and I was doing a terrible job of helping him. For one, I was spread too thin, trying to cover too many roles in the project. For another, I wasn't invested in his success because I wasn't confident about hiring him in the first place. I completely failed this junior developer as both a manager and a human.
We managed to meet the minimum requirements of the funding at the end of those six months – and got an unexpected break when the Harper government severely cut funding to the department that funded the project. The junior moved on to a different team, and I was left with a product that I didn't feel proud of delivering to the public. I spent the next six months rebuilding the project on my own, further delaying other projects in the docket.
I was fortunate, in that I had a very accommodating project sponsor, who trusted me to do the right thing in the end. I realized during the rebuild where I had made mistakes, and what I could do to avoid putting myself into this kind of situation in the future.
The first lesson was that you should never hire out of desperation. If you don't feel strongly that the person you're offering a job to will succeed in their role, then you shouldn't be offering them the position. Anything short of that confidence is doing the prospective candidate a disservice. I learned this lesson first-hand with the junior developer. I knew that he wasn't the right person for the role, but I hired him anyways; the fact that he didn't perform up to the expectations of the position wasn't his fault – it was mine. Had I waited another week or so for another candidate, I may have found someone better equipped to take on the work. Yes, there was a time pressure from the funder; but that's something that could have been discussed and negotiated as an unexpected roadblock, moving the deadline further out.
The second lesson was that by hiring someone on, you are responsible for their success and their failure. I had made a critical error during the hiring process by shifting the burden of mentoring the junior developer to a second hire. That was unfair to both of them. I wanted to be a project and people manager – but I didn't take on the responsibility that required. When the senior dev turned down the role, I didn't make the mental shift of responsibility for the junior. I was too wrapped up in trying to carry the project to completion. And that was a second disservice to the junior dev. Not only was he failing to do a good job with the project – his manager was in no way helpful towards getting him pointed in the right direction.
The final lesson was that I took on too many roles, because I had put myself into a reactionary position. I didn't take a moment to think through the next course of action, and that came back to haunt me. I should have taken time to talk to the funder and get an extension for the project. But professional pride (and a good dose of fear) pushed me to meet the original deadlines and fudge the scope. What I pulled over the finish line was not what it should have been, and it took me a significant amount of time after-the-fact to get it in shipping state.
These were harsh lessons, which I've carried with me since. I've hired several folks since, and each person I've hired is someone I've been fully confident will flourish in the role they're interviewing for. I've also taken personal responsibility for the success of each hire, and ensured that they're set up for positive career growth. If they're not, it's because I'm not creating an environment where they can grow. On one rare occasion, that meant turning down the application of one of my folks for a position I knew they weren't yet ready for (that's a story for another day).
Along those same lines, I've also learned to share my responsibilities and knowledge with those I'm fortunate enough to work with. Taking on too many roles put me in an untenable position, and both I and the project suffered for it. By sharing out responsibility, everyone benefits: the project is healthy because it has multiple folks invested in its success and each has some level of agency in its direction.
In the words of Adam Savage, failure is always an option. But it's not something to be feared, or shunned. Instead, it's a valuable opportunity to learn, and take one step further along the path of personal growth. Embrace it when things aren't going the way you expected, even when they're failing miserably. Because you'll come away from the experience with new knowledge about yourself, your profession, and the people around you.