TNS
VOXPOP
Where are you using WebAssembly?
Wasm promises to let developers build once and run anywhere. Are you using it yet?
At work, for production apps
0%
At work, but not for production apps
0%
I don’t use WebAssembly but expect to when the technology matures
0%
I have no plans to use WebAssembly
0%
No plans and I get mad whenever I see the buzzword
0%
Frontend Development / Software Development / Tech Careers

Making Career Decisions During a Time of Tech Layoffs and AI

With tech layoffs and generative AI causing havoc in the developer profession, we interview a senior engineer who recently went solo.
Mar 31st, 2023 8:00am by
Featued image for: Making Career Decisions During a Time of Tech Layoffs and AI
Image via Unsplash 

It’s a strange time for developers, with the double threat of tech layoffs and generative AI causing an almost existential threat to the profession. In times like these, it’s useful to know how industry veterans are tackling these challenges. With that in mind, I interviewed Robbie Clutton, who has worked as a senior director at Pivotal Labs (and stayed during its transition with VMware) and was most recently a senior engineering VP at Snyk — until being made redundant.

Now he is going solo, so I asked him how it’s going and what tips he’d offer to others (young or old) in a similar position, or who simply want to prepare for the possibility of layoffs.

Disclosure: I first met Robbie as a young colleague in British Telecom (BT), so this was also a great chance to catch up!


You have always been technical, but not in a head down sense. And you have clearly shifted into management without difficulty. Has that been to look for wider horizons, more leadership or just following a natural upward trajectory?

Even from BT days I had feedback that I was able to “talk with the business”, and through that I got some great opportunities — like being invited to participate in acquisition due diligence and getting involved in programmes like the Microsoft Imagine Cup Innovation Accelerator.

I actually resisted the management path for a long time. It wasn’t until joining Pivotal Labs that I took my first step. Managers there were still coding on projects 90-95% of the time. I felt I could dip my toe into management without feeling like starting a new career. Pivotal Labs was a consultancy (it has since been acquired by VMware and is now known as VMware Tanzu Labs) and as such was client facing. I was asked to join pre-sales meetings where we’d scope projects before writing a proposal. I enjoyed talking with clients, learning about their challenges, goals, and facilitating workshops. That evolved into taking on a role as part of the leadership group for Pivotal Labs in New York, where I was based for a few years. I felt going into that role that I could always go back to engineering if this didn’t work out, but I’m still on that path 9 years later.

I grew up with Pivotal in many ways. The company grew from a thousand to three thousand and expanded across Europe, and that aligned with my growth into new roles: from supporting an office (first New York then London), to running the London office, before finally running our EMEA business.

When you were first working at Pivotal, it looks like you were using Rails, Javascript and SQL — roughly the full stack — to work on engagements. Did you weigh in more with javascript frameworks, sql or back end code? When you wanted to make efficient contributions, which tool did you feel most comfortable with?

Pivotal Labs strived to be full stack. There was a practical reason for this. As a consultancy you want people on billable projects, and generalists tend to be easier to allocate to projects. People had interests in certain areas for sure, and there were times where we had some dedicated engineers for iOS work, but generally it was full-stack. This was for the consultancy side, our R&D teams were more focused on server-side and distributed systems like cloud and data products we sold.

Do you groan when another JS framework appears? You hear arguments about SQL / NOSQL? People rave about Rust?

Groan might be a strong word. I think arguments about one technology against another are rarely conclusive. There might always be a good use case for either. I might get closest to a groan however when more time is spent on these type of arguments, rather than discussions of adding business value and improving metrics. We’re starting to see some trends come full circle also — server-side rendering for example.

Early cloud has been good for us, as we have seen it from Heroku and Cloud Foundry upwards. We were using Amazon S3 and EC2 at BT. How were you seeing the public cloud / private cloud argument move in your engagements? And have you tilted to lambda?

It’s evolved over the years. While many startups have been “cloud native” since their inception, many larger companies were resistant due to regulatory concerns. Some of the advantages of what Cloud Foundry offers is the ability to have both private and public cloud, so you could “burst” from one to the other, and have the ability to leverage multiple clouds at the same time, which could be leveraged for price arbitrage, using the best products from each cloud provider, or resiliency of hosting applications across not just multiple zones, but multiple clouds. I haven’t really had the opportunity to explore lambdas that much.

What I would say is that options like Heroku and Cloud Foundry intentionally take away a lot of infrastructure concerns from the developer, meaning they can focus on application concerns like achieving business outcomes and metrics. That doesn’t stop developers wanting to dive into the details of Kubernetes and infrastructure-as-code (IaC), though.

Which Agile practices did you insist on? Did you see agile as mainly a culture glue, or a good set of working practices to help share a mindset? Information radiators or Trello?

I think it’s critical to create space for dissent, and positive tension. From there, concerns can be shared, improvements suggested and then implemented. I think the best place we have today in any formal agile practices is the retrospective. If you could only have one, I’d have that — and make sure they’re good retros. Any team could implement what we might recognise in agile teams from first principles.

There’s also way too much adherence to agile as a prescriptive process versus agility as an emergent property. Too much “the book says this”, “the training said that”, or “company X does it like this”. I like to think, and talk about, a toolbox filled with tools; processes, workshops and other things. For a given challenge, you might try one tool or another, until you find one that works for the given context. You allow yourself to evolve and to iterate, both the code and the way of working. However, many want the comfort of a framework to follow.

Inevitably, the market shifts that we have all seen with development teams hit your most recent employer Snyk last year and led to redundancies. This probably helped to accelerate your thinking about going solo. A lot of experienced industry seniors must be considering this path. How are you approaching it in terms of daily tasks and discipline?

I wasn’t thinking of going independent before being made redundant. I’m not sure I would have been brave enough to leave a full-time job. I was interviewing at the end of last year and early this year, but I felt compelled to be in control of my own time and destiny. I’ve been in the industry 18 years, and I’ve likely got another 18 years or so to go. I felt that if I didn’t do something like this now, I might regret it. I do wonder if this is a second order effect of the pandemic though. The first order is the desire to be a remote worker with the flexibility that comes with that, and in turn offering more flexibility and control about who you work with, and what you work on.

I wrote about what I’m doing with daily tasks in my new blog, where I’m following the ‘Make Time’ approach of having a daily highlight and an end of day reflection.

Robbie, what the hell is a fractional engineering leader?

It’s a fancy way of saying part-time. Ultimately I am working with clients a few hours or a few days a week. This might be a startup who might not have the funds or needs to hire a full time CTO or VP, but needs a bridge between now and when they will need that; a company who is actively hiring for a full-time role, but knows that it’ll take several months to go through interviews, notice periods and onboarding. It might also be working with larger companies on a given initiative, working closely with existing engineering leadership in a CTO, CIO or VP capacity.

Finally, to give others a steer, what practically do you see that you need to do to up your skill level regarding AI? Do you view it as something you need only have a light understanding of? Are you getting into transformers? Or do you see it as just another service that won’t have much impact for your role now?

This is a tricky one. I think we’ll see more AI being used in more ways, so I think it would pay to learn how to use it. But maybe only as much as you need to learn, much as you use a database or search engine. The real trick here is that databases and search engines are predictable. If given the same inputs, they will give the same outputs. That likely won’t be the same for AI, which may influence how deeply someone would want to learn about what is happening under the hood.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.