Why we got rid of all our front-end and back-end engineers
Alex Charalambides
Originally posted on the Insider Inc. Engineering blog.
Well we didn’t really. We changed the way we work.
Engineering teams in a fast-growing businesses need the ability to adjust and adapt to its rapidly-changing demands. What worked yesterday may not work today. For us at Insider Inc., taking on established media giants requires us to do a lot with a little. And this means we have to be flexible.
When I joined the company, we were in the middle of a team transition. The organization was matrix’ed with its reporting structure distinct from that of the operations. Members of my group operated as part of “feature teams”. Each team comprised of mixed-discipline engineers so that they could work on anything.
But here is where it got tricky: they reported into either one of two teams - Back-end Engineering or Front-end Engineering (with corresponding titles).
I decided to re-organize the team to simplify the reporting lines, and in the process, remove the distinction between front-end and back-end.
Everyone is simply known as a Software Engineer now.
Why was this separation of teams a problem?
From the outside looking in, the feature teams seemed balanced, so superficially it didn’t seem like much of an issue. Engineers often have a preference for front-end or back-end and are able to focus their craft as such. If a team has a specific focus that requires only one type of work, then it’s probably not a problem. The main issue arises when you have an engineer that wants to “cross to the other side”, and then come back. Issues about ownership, stepping on toes and “staying in your lane” start to pop up.
By making a distinction between back-end and front-end, we had created an unseen obstacle for engineers looking to expand their knowledge. The barrier promoted a “tossing it over a wall” mentality when something fell outside of the teams-members narrow scope.
The best engineers in the business find ways to push themselves outside of their comfort zone to learn new things. By eliminating this barrier we helped provide an unobstructed path for our engineers to do just this. The hardest type of engineer to find, let alone hire, is the full stack engineer*. Why would we want to put up obstacles to prevent our own talent from trying to achieve that?
What was the result?
We’ve seen a higher level of cross-discipline collaboration across our teams. Engineers now have the agency to try things outside their previous lanes — as well as outside of their comfort zones. This new approach has resonated at hiring events, where applicants have found this philosophy interesting and felt assured that at Insider, they wouldn’t be locked into a specific track or technology.
Harry Hope, Director of Engagement at Insider Inc., put it best, “We want our engineers to function as generalist problem-solvers who can adapt to changes in the business and apply the right technology choices to the problem at hand.”
I think we’ve taken a big step towards achieving this.
*I was once told there is no such thing as a Full Stack Engineer, to which I say BS.
Looking for a new job opportunity? Become a part of our team! We are always looking for new Insiders.