In this guest post, Steve Lowe, CTO of student accommodation finder Student.com, introduces the concept of T-shaped engineers and the value they can bring to teams tasked with delivering DevOps-led digital transformation
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In an increasingly complicated world, businesses are constantly looking at how they deliver safe, stable products to customers faster. They do this using automation to create repeatable processes , paving the way for iterative improvements throughout the software development lifecycle.
If you read articles on DevOps or agility, you will come across references to security working more closely with Dev or Ops, with Ops working more closely with Dev, or cross functional teams.
To me these are all the same thing. And the logical evolution is they will become the same team: a team of engineers with enough knowledge to solve problems end-to-end and invest themselves in the outcome. To achieve this, a cross-functional team is nice, but a team of T-shaped engineers is better.
Making the case for T-shaped engineers
It’s important to understand all of your engineers are already T-shaped. They will have different skills and experiences, including some not quite related to their primary role. This is certainly the case if they have previously worked at a startup.
Equally, if you take a look at your ‘go-to’ team members, they probably don’t just specialise in one technology, but also possess a good breadth of knowledge about other areas too.
There is a reason for this. When you have a good breadth of knowledge it allows you to solve problems in the best place, leading to simpler solutions and that are easier to support.
Now imagine instead of having a few ‘go-to’ team members, you’ve developed your whole team into T-shaped engineers. Engineers who can use a multitude of skills and technologies to solve a problem, and aren’t constrained by the idea of “this is what I know, therefore this how I’ll solve it”.
By developing T-shaped engineers, you end up with a better and more resilient team ‒ where holidays and sickness have less impact as someone can always pick up the work ‒ and (usually) an easier to maintain and manage technical solution.
Tapping up T-shaped talent
The real challenge, of course, is finding a large enough pool of T-shaped engineers. For some reason, in a world where solutions are almost always built using multiple technologies, we have developed extreme niches for our engineers.
And while that drives great depth of knowledge on a subject, most problems no longer require that depth of knowledge to solve ‒ or the only reason that depth of knowledge is required is because your engineers don’t know a simpler solution using different technology.
The only solution to this challenge that I’ve found so far is to ‘grow your own’. Find people willing to learn multiple technologies, make it the primary requirement for your hiring, encourage cross learning, and support your team with goals that reward developing a breadth of knowledge.
Scale and right size the team
But let’s suppose I want a bigger team, so I can go even faster, how do I scale when my team is cross-functional?
First, it’s important to make sure having a bigger team will actually make you go faster. If you have a small code base, more engineers might actually just get in each other’s way and you’ll have to work on better prioritisation to make the best use of your team.
Assuming you can bring in more engineers to make a difference, dividing and managing your team requires microservice architecture. If your system is engineered as a group of microservices, then you can separate your microservices into functional areas and then build teams that own functional areas.
There are several benefits around not dividing engineers by technical expertise. First, your team is still focused on an end-to-end solution. There is no more ‘Dev Complete’ ‒ it’s either ready for your customers or it needs more work.
Second, as long as you keep your interfaces between functional areas strong and backwardly compatible, different teams are free to solve their problems with the best technology for the purpose.
This gives nice separation and makes it easier to empower teams and reduce the coordination overhead. It also gives you a good answer as to how many engineers you need to run, develop and maintain your product.
They are simply a function of the number of functional areas that make sense for your product. For the smallest number of engineers, it’s the minimum number of functional areas that makes sense (usually one).
If it’s a question of going faster and how many engineers do you need, it’s simply a question of efficient team size and how many sensible functional areas you can divide your software into.
Why the timing is right
To understand why the timing is now right, and why this wasn’t always good practice, we need to step back and look at the overall picture.
Cloud services and APIs are everywhere, and lots of us are now integrated with a number of services. Infrastructure as Code is a reality and open source is now widely accepted as a must-have building block in most technology situations.
This combination means, to build a modern piece of software, depth of knowledge of any given technology is less important than breadth of knowledge in most cases.
Lots of the complexity is abstracted away, and building most of your solution will involve integrating a mix of open source and third-party services in new and interesting ways to solve a specific problem.
This allows engineers to focus on building a breadth of knowledge rather than a deep focus on one specific technology, so they can solve your problems efficiently.