Breaking down the barrier between engineering disciplines

Agile SDLC is in the mainstream and proven to work; technology leadership is looking for additional ways to increase the competitive advantage of engineering teams.  The days of everyone being a technology specialist are coming to a close for many software engineers.  Software engineers are expected to not only write code, and unit test but are also being asked to write integration and system tests, create deployment pipelines and support systems.  The solid lines that once separated Dev, Test and Ops are quickly being erased and expectations have been raised where all engineers are expected to be a Subject Matter Expert (SME) in one or more areas but cross trained in other areas.  This provides a big win for the organization as it allows teams to remain together even when the feature area changes dramatically, because as we know the business never changes their mind.  This additional flexibility allows the team to quickly pick up new areas and grow expertise in new feature areas while retaining the benefits of high functioning, cohesive team as opposed to old way of managing teams – breaking up the team and reforming constantly to meet changing business needs.

How often have we been faced with the issue of a key resource being out and they have the only knowledge of that functionality or technology.  We all know that people are never sick, take vacations, have family emergencies, or leave for other jobs ….

As a technology leader I’m always looking for ways to get that competitive advantage for my employer.  My engineers are expected to cross train in several areas so that my team can fill in for other team members when they’re out.  This allows us to be functional and flexible in the work we take on – a key win for the business as they expect us to complete work on schedule while life goes on around us.

Developers in addition to writing code also write test cases and execute them, SDETs write production code and everyone does deployment and support work.  We want to work on the highest priority work first, not the work that people have the competency to do first.  At the end of the day we don’t have dev, test and ops – we simply have engineers who are well qualified to take on any task.

This approach requires some investment – we do a lot of pair programming.  Two engineers, one computer, keyboard, and mouse.  Taking turns designing, coding, debugging, testing, deploying. 

It’s easiest to do this when forming new teams – setting the expectation that this will be the way the team works prior to them starting is best.  This isn’t always an easy transition for existing teams to make.  Being open to change and adaptability requires a special individual and not all engineers are equal in this respect.  Some teams take longer to make this transition but in the end once the change has occurred no one wants to go back to the old ways of working.  Cross trained teams are happy teams.

I’ve been able to make this change successfully at a few companies that I’ve worked.  If you’re considering making this change – be ready for some pushback not just from the team but also possibly leadership.  To convince leadership this is a relevant and necessary change bring up these as wins for the business:

• Higher Quality
• Improved Business continuity
• Speed of delivery
• Team cohesiveness and happiness

When trying this out with the team – you want to emphasize the benefits of being on vacation and being able to disconnect from work and know that it’s in good hands.  If the team pushes back start with 2-3 of your most adaptable team members and have them pilot it.  Ultimately, the success of change lies in your ability to show that it actually works.