anthony galvin
TAGGED: SOFTWARE
Specialists and generalists: The challenge of building multi-stack engineering experience
When I started off in web development, back in the last century, everyone was a generalist. And generally people didn't really know what they were doing. Which was fine, we made it up as we went along, learning little bits along the way. For most engineers working with the web, the problems weren't that complicated. Tying to get your blink tag to render on various versions of IE and Netscape Navigator. Infuriating for sure. But in the grand scheme of things not that complex.
Fast forward 25 years or so and complexity abounds. Or it can do. Especially for bigger organisations working with bigger teams on (hopefully) bigger problems. In the front-end world new frameworks have supercharged the user experience of many web based products and services. With the added complexity and learning curve that a power tool demands. App development, for a while the home of the 'native' developer also has a plethora of cross-platform and alternative authoring options. These promise (though don't often deliver) a simplified development environment. Away from the front end, contributors to languages such as Grails, Python, GoLang and node.js add more and more features. Promising better, more powerful tools, with an ever improving developer experience (I said promise).
So where does this leave engineering teams and hiring managers. In a medium sized tech company nobody can know the entire architecture and tech stack. At least not with any mastery beyond some boxes on an investor presentation. It takes a team to deliver and in most organisations lots of different skills.
When hiring engineers, I always enjoy learning about how they solve problems that I don't see everyday. I meet a lot of candidates. It's fascinating how peple deploy so many different tools and technologies in such a variety of combinations. Sometimes people describe themselves as "full stack engineers" - which isn't a phrase I love. Full stack invariably means some back-end and some front-end engineering experience. But it doesn't mean the entire stack. No one person at TodayTix Group is able to deliver with mastery across every part of our architecture. We don't expect any one person to do so.
But we still hire full stack engineers. Teams taking on a problem need to be able to solve that problem regardless of the technology or tool that it touches. Which is why we have cross-functional teams with a mix of skills, experience and perspectives. Good engineering practices and process can go a long way regardless of the technology in play. The best full stack engineers (or multi-stack engineers for want of a better label) can bring multiple points of view. Arguably good engineers are generalists. However, complex problems often need someone to focus on a specific area, and in tech companies that specialism can get very, very specific. Which can be good for the organisation and very rewarding for individuals, at least for a while.
When I say a while, I have a specific example in mind. When I joined TodayTix Group I inherited a migration project. The goal was to integrate an acquired business. Moving off a legacy main-frame system that was decades old. Many of the project team had been maintaining this system for decades as well. They were true specialists. Day to day work for the team was a combination of being a care worker, therapist and engineer. But their decades of deep specialism hadn't equipped them or the company for the future. This wasn't the fault of the team. A failure of leadership had stymied technology strategy. A failure of people management and career coaching. Aligned with diverging company and individual priorities. The longer the business stuck with the mainframe the less incentive it had to develop the engineers supporting the system.
In a career as an engineer it makes sense to focus on the challenge at hand, to specialise in technology and tools that benefit you and your team. The path to being an experienced engineer is to build experience. Learning a new framework isn't experience. Solving some real customer or business challenges with it is experience.
But focussing on a single tool without taking the time to check-in on wider developments in your industry and chosen field is limiting. Ideally your manager should be taking some time to help you get this kind of perspective. But that's not always the case - especially if you're not a full time employee, work for yourself or work in a smaller organisation (and unfortunately in some bigger companies too!). If that's the case it's important to find other ways to do this. To have someone who you can chat to about career development, technology changes and what that means for you.
The goal for more experienced engineers is to be a general specialist. Someone with a variety of experience in different technologies, with knowledge of one or two technologies that are current. Like gardening career development is easier if you do it a little and often - not go on a training course once every 10 years.
22/12/2022 permalink
It's taken me a while to come to this realisation, but I've spent a huge chunk of my life trying to achieve things with teams. Sports teams, software teams, bands, orchestras, actors and product teams. To be fair not all of these notional teams have been successful - but when they work well, teams are awesome.
It's a cliche to say that "being a team player" is important at work. Most of the time this is just a platitude for people who don't rock the boat. A way of saying that the person in question is no trouble. I don't always buy into this team of mates dynamic.
To continue the cricketing viewpoint, Mike Brierley, arguably the greatest exponent of captaincy and understanding the psychology of teams sums it up nicely "If individualists are too powerful, too divisive and too selfish, the team suffers. If they run riot, the notion of team scarcely exists. At the other extreme, some teams can become flat, conformist and dull. Far from running riot, individuality is suppressed."
So there's plenty of scope for the right kind of discussion and a team that's able to sometimes hold divergent points of view, at least for short periods of time.
It's not always easy to identify the right group dynamic from the inside, never mind on the outside. In my experience it's one of the reasons why agencies often struggle with consistently casting high performance teams. Even if resourcing is operating beyond the principle of "availability as a skillset", the people making the decisions when pulling together new project teams are on the outside, and from there the signals of a genuinely good team are almost impossible to detect. In an agency it can sometimes feels like the approach is "We've got this project team performing really well. Now we've delivered everything we should break the team up and make sure this group of individuals never work together again".
I've written recently about some of the challenges in scaling teams across multiple locations, but as well as geography having a significant impact, more people also comes with a time cost.
More people doesn't have to mean your people. As the number of integrations, partners and vendors increase the time cost of managing, motivating and co-ordinating all these different folks can have a significant impact. A small team that has many thrd-party integrations doesn't just have a scope challenge, it also has team management challenge as well.
Perhaps this is the ultimate team challenge - when the team in question isn't just your team, but other teams as well.
25/02/2019 permalink
It often starts with a sigh. Away from work you hear the obvious sound of frustration when an app or service doesn’t work as expected or crashes at a critical moment. As more and more of our lives are mediated through different glass rectangles, the expectations and importance of delivering brilliant, scalable and reliable experiences on those devices grows.
Which means in practice that the numbers of people involved in creating and engineering the apps and services that people rely on are inevitably large. One of the challenges for people like myself responsible for delivering the software to make all this happen is that with so many people involved how do you create an environment that delivers high quality software and services.
It’s a bit of a management speak truism that everyone on a project is “on the same team”, but in practice that’s not really possible. For some of the global projects I’m working on at Huge, there’s often over 100 folks involved, with a large percentage of these made up of engineers in variety of locations. We have a common objective but in practice we are many teams.
Where location does play a factor is often around balancing time zone coverage so that there’s enough people in each location to ensure effective collaboration. There’s no point adding a single developer with almost no time overlap with anyone else on the project.
However, in practice the amount of overlap doesn’t always have the positive effect people might think. Complex engineering problems require deep focus and an environment that reduces interruption in addition to cross discipline collaboration. The reality of a distributed team is that at some point of the day there are times when there’s fewer people online. Which correlates with fewer interruptions.
Would I choose to have the engineering teams scattered across the planet if it was possible to have everyone in one building. Probably not, but the reality of the work is that this isn’t really possibly, and in practice it’s not the most important piece of the puzzle.
10/11/2018 permalink