Category Archives: Leadership

Joining TheTradeDesk (BOOTCAMP!)

Three weeks ago, I started my journey with TheTradeDesk. Working for a US-based scale-up has long been one of my dreams – I’ve come really close a few times, including turning down an offer to move to Seattle a few years ago due to a previous long-term relationship. But this time it finally happened – and the experience so far has been great.

My favourite local spot for a bit of (picturesque) remote work

I’ve really been enjoying inner-city living in Brisbane (especially some of the great remote-working spots I’ve found near my apartment), but TTD has proven very open to remote work. Their closest physical office is Sydney, and they’ve promised me trips there as well as to the US offices (COVID-permitting – and it looks like it finally will).

BOOTCAMP!

TheTradeDesk has a great initiative called Bootcamp. New starters don’t go straight to the team which hired them: instead they join their local bootcamp team (for around 8 weeks) to make sure they get a great on-boarding experience. This makes sure new starters get a chance to learn properly, rather than being thrown straight in to delivery-pressure mode.

I’ve been given plenty of time to learn: I’ve spent time, among other things, learning about our employee stock program, our T4 template code generation, our EF Core standards, and our extensive Engineering Meta repository – the source of truth for our extensive and open-to-contribution software engineering standards. I’ve also been exposed to real tickets – bootcamp participants are given a variety of non-time-sensitive tickets from across the organisation to give them real-world opportunities for hands-on learning.

I think this is a great way to onboard people, but I’m also really looking forward to taking on the full role I joined TTD for.

Staff Software Engineer – Front-end

Any readers who’ve known me from earlier in my career will recognise what a big shift it is for me to go to a front-end-focused role. I started my career as a back-end engineer with a well-developed allergy to anything front-end, but over the years I’ve done the needful – which has often been to make sure my team’s front-end engineering is keeping up with the trends.

This is a shift back onto the tools as well. I’m still developing my sense for the right ladder-vs-pendulum approach for my own career, but I’m confident I’ll enjoy getting back to coding for a while. I can’t keep myself away from writing code even when I’m meant to be focusing on being a manager, so this is a very comfortable shift for me.

A new sense of scale

One of the things I wanted most of all with this job change was the chance to learn – and I have that in spades. For a start, I’m faced with the largest code base I’ve ever worked on. More interestingly, the data involved creates genuine engineering challenges: TheTradeDesk deals with true web-scale (and I mean “a large fraction of the web“-scale) loads, dealing with upwards of ten million requests per second (that’s over 800 billion requests per day!).

Along with the engineering challenges, we are a rapidly-growing organisation, planning to significantly increase our software engineering team in the coming year. That creates plenty of opportunities for me to contribute to initiatives that will help grow our team – something I’ve been passionate about for a long time. Everything I’ve seen so far makes me very confident in recommending TheTradeDesk as a great place to work for people at any stage in their career.

If you’re interested in learning (don’t worry if that level of scale sounds intimidating!) maybe TheTradeDesk would be a good next role for you too.

Hiring

If any of that sounds interesting – please get in touch. Particularly if you’ve worked with me before! While TheTradeDesk has no current plan for a Brisbane office, I hope to thwart that lack of a plan by helping to recruit a heap of new engineers in Brisbane. I’ve worked with so many talented developers over the years, and I would love to see some of them join TheTradeDesk. We’re focused on hiring a balanced team, so I’m particularly keen to hear from early and mid-career software engineers looking for a career change (but there are roles for more senior engineers as well).

If you’re interested, start by getting in touch with me – you can find me in all the usual places (LinkedIn, Twitter, or @rophuine in some of the local developer Slack groups). We’re particularly looking for .NET and React developers, but we’re open to people with other skillsets (and we also need account managers, BI analysts, data engineers, and more!).

Make Your Job Suit You

Have you heard the advice “Do what you love, and you’ll never work another day in your life”? Or how about the Japanese concept of Ikigai, where you should find the intersection of what you love, what you’re good at, what the world needs, and what you can get paid for, and do that? (My apologies for what I’m sure is an awful attempt to sum up a philosophy in one sentence.)

I have. I read those advice pieces regularly, wonder if there’s room to refine where I’ve ended up, and then shrug and go back to the job I really like (most of the time) which pays the bills (as long as I’m not too extravagant). I’ve done OK by those measures – perhaps better than most. But I’ve always wondered whether it’s actually useful advice? As a trite throw-away line, I’m pretty sure it isn’t – but if you go a little deeper I believe there’s something useful there.

This article is going to go a little deeper – but first I need to set some context. “Show, don’t tell” doesn’t just apply to fiction. If you really want to skip the rambling and get to the actual point, scroll down to the section titled “The Actual Point”.

Writing My Own Job Description

I’m leaving my job shortly. As I write this, I have one week left. The job I’m leaving is a “management” role (it says so in my job title!) and I was the first person in the role. I didn’t start the team, nor was I the first person to have play a leadership role on the team, but I was the first one to play a purely-overhead, non-developer role (although when I started, there was an intent from both sides that I would be on the tools).

That means I got to write the job description.

To be fair, someone else wrote a job description before I took the role – but they hadn’t done the job, and they didn’t really have a deep understanding of what would be involved. The role started as an informal one: I was a senior consultant, and the job was a team lead one – but for a particular long-term team, rather than our usual temporary project teams. Later, the role was formalised, and I applied for it, interviewed, and officially became “Regional Manager” (to some minor applause and a significant number of The Office jokes). I won’t dig up the original job description, because it’s just not relevant – I don’t think I even read it when I applied. It certainly didn’t guide what I did. I knew what needed to be done: I’d already been doing it for years.

Having recently resigned, and needing to help find the right person to replace me, I sat down to describe what I actually do. I thought about what my one-up had said when I asked what he expected from me early on. “Happy clients, happy team.” Great advice, but a four-word job description probably won’t cut it! Perhaps reasonably, I started reviewing all the things I spend my time on. First at the day-to-day level, then at the monthly level, then the longer-term things. I looked at what changes I’d helped achieve, and thought about how I helped achieve them. If I can find someone who can keep doing the things I’ve been doing for the past few years, I thought, they’ll keep achieving the success I’ve been achieving!

Perhaps you can see the problem with that idea. Hiring someone to repeat the patterns of the past isn’t necessarily the best way to lead the team into the future. That’s not the lesson here, though – although I’ve just added that article to my backlog. I zoomed out a little – I described the goals I had pursued, and (to a lesser extent) the outcomes I’d been hoping for. I looked forward as well: what outcomes do we need in the future? They’ll be the real responsibilities of my replacement. Or perhaps they’ll even decide they’re not actually the right outcomes, and come up with new ones! That’s the real job.

Anyway, after a few more rounds of zooming in and out, reviewing and editing, and seeking input from my colleagues, I had what I thought was a workable job description. Only there was a problem.

There is no way I would have applied for that job.

I like my job. Quite a lot. I’m not sure I’d say I love it, but I work with some amazing people, I get to see a lot of different clients (we’re a consultancy, after all), and I have the autonomy (for the most part) to organise the team as I see fit. I pass a lot of that autonomy down to my team, to organise themselves around the clients and problems they’re facing. That wasn’t the problem. The position description didn’t make it sound like an unlikeable job.

It made it sound like an unapproachable job.

Echoes of Imposter Syndrome

“I’m not qualified for my job!” is a thought I’ve had plenty of times throughout my career, but not recently – and I didn’t quite think that now. I seem to have succeeded in the role. The things people have said (particularly since I resigned) and the metrics of the team I manage suggest I’m doing pretty well.  But I know that if I’d seen that job ad a few years ago, I probably wouldn’t have applied. It was too intimidating. If I saw it today … the same. It’s too much. I’m not ready for a job like that!

I had two adjustments to make. One to my own expectations of myself. I can do a job like that! And while the expectations of the role I’m going in to won’t be quite so lofty, there’s a good chance I’ll turn it into something just as big. I’ll broaden my responsibilities, I’ll fine-tune the role to suit me, and when I leave people will (hopefully) talk about how I have big shoes to fill. That leads me to the second adjustment I needed to make.

I added a sentence to the beginning of the position description. “The right candidate will have the opportunity to shape the role to fit their strengths, and delegate some of the following responsibilities and goals to other members of their team.” I think all leadership roles carry this implication, and we might find more people would be comfortable in stepping in to leadership (and be better at delegating) if we made it more explicit up front.

That’s still not the main point of this article, but I have finally arrived at it.

The Actual Point

Whether or not you’re in leadership, you should find ways to make your role suit you.

The real insight I came to is that the role description only looks the way it does because I’ve shaped the role around my own strengths. I hunted around looking for ways we could be better, and where I found something I would be great at, I added it to the list of things I do. Where I found something that would be highly valuable that I would be bad at (or was too far from my sphere of influence), I tried to get someone else to do it. Had another person been in the role instead of me, and they’d actively shaped it to suit themselves in the same way I did, the role would probably look different – and they’d probably like it just as much as I do.

That’s fine advice, Lionell (you might object), but you’re a manager! Individual contributors (ICs) don’t have the authority to do that!

It’s true that I have more authority than I did as an IC, but I also have a broader variety of larger-scale outcomes I’m on the hook for. I’ve been shaping my role to suit myself for most of my career, and it hasn’t gotten any easier now that I’m in management. Whether you’re a manager or an IC, it’s tough – but it’s also extremely rewarding, and I think everyone should try to do it. You won’t always succeed (I’ve certainly had jobs where I couldn’t make it work), but you won’t know if you don’t try.

It’s Not All About You

It’s not just personally rewarding. It’s likely to be great for your team, as well. In one role where I was a senior developer or a tech lead (to this day I’m not quite sure), I advocated for 20% time – where developers get the freedom to spend 20% of their time on side projects. We didn’t get 20% time – but we did get 10% time, and one of my first 10%-time projects was to build a proof-of-concept user interface for our flagship product based around Google Earth. It was extremely well-received, and while we ended up pivoting to Google Maps instead, that layout became core to the product for many years to come (it might still be that way).

In another IC role, I put my hand up for presales work every single time the sales team needed an engineer. I enjoyed it, I built some great skills, and I helped us close some deals which we might otherwise have missed out on! Or maybe I lost us some deals. At least, I helped make sure engineering had a voice at the table early on. My goal was not to win or lose deals, but to help shape opportunities into successful projects. It meant my engineering work was regularly interspersed with presales work, and I loved the variety.

Back to my current role: that presales experience came in mighty handy. I’ve done presales work on just about every new client my team has picked up in the last three years. I’ve loved that part of my job! But if I’d hated presales, I wouldn’t have done all that presales at a previous job, and I would probably have left it to others. Hopefully I would have found someone on my team interested in it.

Advice for Individual Contributors

If you’re an IC, I can’t tell you how much of your current role will be negotiable. Perhaps it’s only 10%. Perhaps it’s 100%. If you keep scanning your sphere of influence for things which need doing, pick the things you think you’d be good at, and ask to do them, you’ll find out. If you don’t know how to find things which need doing, ask your manager! Tell them that you’re looking for opportunities for expanded responsibilities, and tell them what kind of things you think you’d be interested in or good at. Most managers I’ve met have too much on their plate and will be happy to offload some of what they do – but watch out for them giving you busy work. A great manager will give you opportunities which you can learn from and feel good about. A poor manager will just give you the menial tasks they hate.

One thing to watch out for: if you’re very early in your career, be wary of a trap I’ve seen some people fall into. Don’t let yourself end up as a gopher (“Hey [name], go’fer coffee” / “hey [name], go’fer [other task]”). You need to be learning the fundamentals of your craft, and that means spending plenty of time on the tools. A little extra responsibility is a good thing, but you shouldn’t over-do it and you shouldn’t let yourself be de-valued by getting all the menial tasks. Picking up coffee for the team is the kind of thing that should probably be a shared or rotated responsibility, not a task given to the most junior IC on the team.

Advice for Managers

If you’re a manager, you (hopefully) already have the autonomy to build your role into something you will like (or even love). The more senior you become, the more your responsibilities should be focused on achieving outcomes with your team, rather than doing specific things personally. If you’re not already taking advantage of this – get on it!

There are three things I’d recommend a new manager flexing their autonomy-muscles watch out for:

First, don’t lose sight of the actual goals you’re responsible for. This isn’t a license to just do whatever seems fun and forget your responsibilities! Even more importantly, don’t lose sight of the fact that one responsibility every manager has is to build up their team. Don’t keep all the fun jobs and delegate all the rubbish ones: that would be failing in that responsibility.

Second, be aware that you’re part of a broader organisation, and there are other people around you with their own goals and passions. If you think you’d absolutely love to run a customer-facing product forum, but there’s already a community engagement manager running a customer-facing product forum, this isn’t a license to go start your own competing one! Instead, see if there’s a related gap: perhaps there’s an opportunity to launch a public Slack or Discord group focused on your product. Perhaps there’s just no need, and you’ll need to scratch that particular itch on your own time (maybe by finding an open source project or not-for-profit group in need of a spare-time community manager).

Third, be aware of the time costs of the things you take on. If you’re the CTO, spending half your time moderating a community forum is probably not what you’re being paid for. Keeping an eye on trends in a community forum and making sure you understand how your users see your product might be, though! If there’s no community forum right now and you think there should be, delegate. You get bonus points if you can find someone in your organisation who would love to take on that responsibility for you.

Finally…

My final advice is to take your time over this. You’ll get the best outcomes if you find things to do which not only help you like your job more, but let you learn new things and help the team around you achieve better outcomes. If I had to choose, however, I’d focus on things which make me happier. You might be surprised just how valuable it is to your team for you to be happy at work!

How I Learned to Stop Worrying and Love Consulting

A few months ago I wrote about my motivation problems since switching to consulting. I think this was a somewhat natural thing to feel: I’ve built quite a few in-house software teams over the years, and consulting companies were my natural enemy. They hired many of the top people in my local area, and then wanted to sell them back to me at a substantial mark-up. What jerks!

A little over a year ago, I joined the dark side and became a jerk consultant. My former enemies are now my friends, and I’m the one being sold back to in-house teams for profit. I learned to live with that fairly easily: if we weren’t giving our clients value, they’d stop paying us – and we get heaps of repeat business. No, the economics of it weren’t the problem.

The problem was Mission.

I’ve always thought of myself as strongly mission-driven. When I worked in finance, I believed that what we were doing was making life better for our customers. When I worked in environmental engineering, I believed that we were helping our clients get the most environmental bang for their buck (my more cynical side occasionally observed that we were helping them spend the minimum possible to avoid trouble with the regulators). When I worked for a hospital group, it was easy to think of patient care as a worthwhile mission, because it is.

Oddly, what I’ve since learned is that my mission is much less available for rent as a consultant that it ever was before. Protecting the environment wasn’t my core mission before my pay check came from Pacific Environment, and it hasn’t been since I left. Patient care wasn’t my mission before I joined Ramsay Health Care, and it isn’t now.

Are those all worthwhile missions? Absolutely. But in hindsight, the mission I took on was entirely driven by who was paying my salary.

Don’t get me wrong. I’m not unhappy with my career choices, and I think I made a positive impact on the world (and hopefully my local software industry) on my way through. But joining a software consultancy is a neat way to de-couple my mission from my salary. I still have a core mission, but now it’s much more in concert with who I am as a person. Readify’s mission is all about using technology to make the future better for everyone – and that speaks very deeply to me. I’m a technologist at heart. My secondary mission may be for sale, but the core goal of myself, my colleagues and my employer remains the same. That’s not just something I can live with: it’s something I can embrace.

So, that’s the mission aspect sorted – but I’m not the moony-eyed idealist I might like to think I am. You could see all of this talk about “Mission” as an exercise in justifying my current choice – just like I justified all of my previous employment choices. What about the economics of it all? That’s where my opposition to software consulting began, and it’s not so shallow-rooted to be slain by a simple mission statement.

Well, here’s where I needed to shift my thinking a little. I needed to start thinking about industry sustainability.

Before I get to the point, bear with me while I give you a quick tour through some highlights of my career. My first significant production responsibility came a few years in, when I was a Senior Software Engineer at a successful FinTech start-up. I reported directly to the Managing Director (who was from a finance background). Some years on, I found myself a Senior Software Engineer and Team Lead for an environmental firm, where I reported to a variety of people (including the CTO, and occasionally the CEO) – who were mostly from an environmental engineering background. During my time in the hospital industry, I was again in a leadership role – being such a large multi-national, there were a few more layers involved, but my boss’s boss’s boss (and most of his colleagues) were from a doctoring or nursing background.

I’ve seen this pattern repeated across many industries: flatly-structured software teams with little or no opportunity for career advancement, reporting to non-software people. Reporting to non-software people isn’t intrinsically bad: some of my all-time favourite people are non-software people (I even married one!). However, I don’t think it’s a sustainable model for our industry. I’ve seen far too many software developers come to realise that their best opportunity for advancement was to move sideways (out of software) – and I think that’s terrible. It’s almost become a truism that “software is eating the world”, and certainly one of the highest-value-creating things you can do today is to build software. Why would I help perpetuate a model which pushes our best and brightest to go and do other things?

Participating in a software consultancy like Readify is a way to break that mould. I’m in a leadership role, but I still have plenty of room to grow in my career without abandoning my core mission and my experience as a software engineer. If I decide that my current business group (we call it “Managed Services” but it’s really a combination of production engineering and feature development, driven in a Kanban style) doesn’t suit me, we have plenty of other flavours of software development I can switch to. If I really want control of my own destiny, I’m learning the business of software consulting – so I can always go and do software on my own terms. Mid-career, I have software developers reporting to me, and I report to other people from a software background – all the way up. I can move up the chain, or try to disrupt it – and either way, I’ll be participating in an industry model which mentors and builds software careers, from fresh graduate to C-level executive. Perhaps most importantly, I’ll be participating in a sustainable model – which keeps people in software, because it’s a great career with opportunities in line with any other you could choose.

Software consulting isn’t the only way to achieve this. Software-focused product companies offer the same potential sustainability. I can’t even rule out that my career might take me back to working directly in other industries – but if I do, it will be with a new understanding of the importance of a sustainable software industry, and an eye to ensuring that the technologists among us never feel the need to go do something else to advance their career.

Enduring Software Development Myths

I’ve been asked more than once about software development myths, and I’ve run into plenty over the years. Here is a (non-exhaustive) list of some of the myths I’ve seen people believe. I’ve tried to focus on enduring myths, rather than short-term fads (like “Blockchain is a broadly applicable technology”).

Myths Management Believes

adult-businesswoman-company-325924

1. Every manager has read ‘The Mythical Man-Month’ and thinks they understand that adding more developers to an already-late project tends to make it later. However, they will still do it, apparently believing that some combination of proper management, having good people, and the specifics of a project mean it doesn’t apply in their situation.

2. Management also has a tendency to believe that large, complex software systems get ‘finished’ and then become a cash-cow, bringing in an ever-increasing revenue stream for fixed costs. Even if they do account for increasing support and maintenance costs, they rarely consider that continuing innovation and development is required to keep a product competitive.

3. Managers sometimes believes that the primary role of a developer is to translate specification into code. They don’t understand the numerous design decisions involved, the trade-offs being made, the non-functional requirements being considered. I have never once in my career encountered a specification which considered the sort of logging detail required to diagnose the types of system failures which might occur – and yet that is a key component of writing good code. Every developer runs into minor details from day to day which require assumptions or decisions to be made – and a good developer should be tracking those, communicating them, and ensuring the right people are involved in the right decisions, while being shielded from the bulk of less-important ones.

4. I have frequently run into managers who believe that their developers are not politically savvy, or that they all have poor networking skills. This can lead them to interact with other parts of the organisation in a way which under-estimates the contribution of the development team (see 3). When managers do this, their team does find out about it, and it creates resentment.

5. Managers sometimes think that developers within their team are roughly fungible. Managers usually understand that different developers have different areas of expertise and levels of experience, but they often underestimate the impact. They don’t realise that it can have not a 2x effect, but a 5x or greater effect – and that effect is not limited to time, but also to quality (but see myth #2 under “Myths Developers Believe”, below).

6. “All platforms, languages, and third-party systems are roughly equivalent” or “This specific platform, language, or third-party system will fix all of our problems”. I have run into both over the years. The former leads to upper management thinking the selection of a third-party provider such as a cloud host or database platform is purely a business decision and will have no technical impact. The latter can result in management embarking on costly technical projects to no benefit (“we have to re-write our entire codebase into [language]” or “we need to move all of our data into MongoDB”).

Myths Developers Believe

devops-photo-m1. Developers often believe that management doesn’t have anything to contribute, or that they’re useless or unskilled. Notwithstanding the above myths, managers can make significant contributions and many of them do really know what they’re doing. The good ones shield developers from distraction, ensure they have proper equipment and software, manage outwards to get realistic (and, importantly, low-stress) deadlines, communicate early and mitigate the effects of missed deadlines, justify budgets and pay increases, bring in appropriate consultants to address short-term skill gaps, ensure meetings minimise disruption, and do countless other things to make projects run more smoothly.

2. Developers often believe in 10x or ‘Rockstar’ developers. Some developers can be significantly more productive than others, but this is usually just a matter of experience and knowledge. It is also often specific to particular topics. For example, I used to do all of my team’s low-level network programming – many on the team considered it an impenetrable field and thought they weren’t capable of doing it. A while ago, though, I took one of our juniors aside and spent some time teaching him what was involved. He is now nearly as productive as me in that area, as long as he doesn’t go too long without working in it. Once he’s relearned the skills a few times, they’ll become a permanent part of his skillset. He’ll then be a 10x programmer – but only when working on low-level networking code, and only when compared to a developer who hasn’t spent much time on that specialty.

3. “Most developers are much better than me.” Known as Imposter Syndrome, developers are particularly prone to it, due to developer myth 2. It is especially common in generalist-type roles, where a developer may go long stretches without working on the sorts of things he or she is particularly good at. Instead of treating these times as opportunities to develop new specialties, they can instead look back at periods of much-increased creativity and think that they’re a bad developer who spends most of their time being unproductive. In reality, they are normally-productive for much of their time, and super-productive when the thing which needs doing is an excellent match for their experience and knowledge.

4. I don’t quite know how this one crops up, but many developers think having a high reliance on tools is bad. I have encountered developers who refuse to use automated deployment systems (“I want to understand what’s going on, and I can’t do that if it’s automated”), refactoring tools (“it’s safer to make each change manually”), and even syntax-highlighting and code completion (“I know my language and my libraries. What if one day I’m stuck using vi on a green-screen linux box from the 70s? Where will I be then if I’m used to these fancy tools?”). I call this concrete-pill syndrome, and I suspect it has something to do with wanting to look capable of handling everything yourself. In reality, these tools (and many others) are great levers, allowing developers to increase productivity and quality.

5. “As a developer, it doesn’t matter if I have poor people-skills, because in developer roles I can ignore office politics anyway.” This is a recurring one, and it doesn’t just hurt your long-term career – it hurts your current project, it affects the sorts of projects you get to work on, and it hurts your team. I try to shield my team from the need to play politics, but I also try to let them see just how much of it I have to do. Not playing office politics well enough can leave you stuck with a bad manager (see some of the earlier myths about the contribution a good manager can make), or it can leave you stuck with a really bad external technical decision. It can leave you stuck with a really bad hire.

Earlier in my career, someone from upper management asked me: “Of the candidates for the developer role you rejected, who was the least bad?” I made the mistake of telling him, and I got stuck with that bad candidate on my team right through his probation period. I should have known to respond with “They were all unsuitable, let’s line up some more interviews”.

6. Developers early in their career sometimes think they are much better than experienced developers. I’ve heard it called ‘God’s Gift to Coding’ syndrome. It happens because they believe they are better with new technology, and new technology is more productive, and so they are worth more than someone who is too out-dated in their thinking or is stuck on old platforms and techniques. While some older developers do remain focused on older systems, they have still built up a depth and breadth of experience which is valuable. However, many developers continue to be intrigued by new technology as they get older, and keep their skills as (or more) current than many juniors.

7. This is a two’fer: “Domain experts outside software aren’t really that smart” and “domain experts have magical knowledge of an esoteric field I can never begin to understand”. The reality is that the domain experts you work with – whether they are accountants, scientists, engineers, or sales people – have years of learning, training, and industry experience which is highly valuable to your team. As a developer, you need to respect that – but you also need to be a sponge, learning what you can about the domain. If you don’t understand what you’re building, you will fail to consider important things. If you don’t rely on your experts for their professional knowledge, though, your project will be built by amateurs who happen to be good at software.

(I originally published this list on Quora but wanted to get it on my own blog as well.)