The IT industry is undergoing tremendous transformation. To a large degree this transformation involves dissolving boundaries:
- Between “the business” and IT
- Between development and operations
- Between corporate and personal devices
- Between internal and external services and customers
IT professionals are having to change the way they think and work. There has been a lot of discussion about what new work skills and styles IT transformation requires. I think the notion of “T-shaped people” is a good answer to this question.
According to design firm IDEO’s CEO Tim Brown, a T-shaped person is someone who combines “depth of skill” (the vertical stroke) with “the disposition for collaboration across disciplines” (the horizontal stroke). This disposition consists of “empathy” which “allows people to imagine the problem from another perspective”, and “enthusiasm about other people’s disciplines”.
It used to be that IT was IT and marketing was marketing. Development was development, QA was QA, and operations was operations. Companies intentionally separated disciplines from each other. Under pressure from the above-mentioned transformations, however, along with Lean insights about waste, the walls are starting to crumble.
Some people think that dissolving boundaries between functions means that everyone has to do everything. Someone once told me that, if I had people on my development team with the words “tester” or “QA” in their titles, I wasn’t doing Agile development, since agile teams self-test. With all due respect, I find that statement to be facile and extreme. With the advent of DevOps, pundits are advising Ops professionals to “learn how to code”. Does that mean the guy who’s spent the last ten years administering Linux boxes needs to start coding AJAX web sites? I don’t believe so. Instead, they need to combine their depth of skill in administration with empathy and enthusiasm for the other disciplines that make up contemporary IT.
What is the spectrum of skills, and how do they need to reach out to each other horizontally? I’ve previously described what I call “User-Centered IT”, which unifies Lean and Design Thinking in the context of delivering software services. User-Centered IT requires collaboration and unity of purpose across:
- Marketing/Program Management
The ability to collaborate with unity of purpose in delivering a software service needs T-shaped people. Everyone can’t do everything, but everyone needs to care about everything. What does “caring about everything” look like?
Marketing, design, development, and QA all care about operational excellence:
- Marketing prioritizes operational integrity engineering, since site outages, slow response times, and security breaches compromise customer satisfaction
- Design considers what happens to the user experience if, for example, the embedded Google Maps service goes offline
- Development designs for performance, and provides application hooks to support operational monitoring
- Testing addresses non-functional requirements
Operations cares about code and about the customer experience:
- If the servers and network are all up, and the disks have plenty of free space, but the blog-platform commenting feature doesn’t work, then the site can’t be considered “available”
- Ops engineers help designers and developers understand the operational implications of UX and application design decisions
Everyone cares about support:
- Support is the flashpoint of the customer relationship. If the application is poorly written, or the infrastructure is unreliable, support gets slammed. If things get too bad, they start looking for another job
- Support has the most direct understanding of the customer’s real experience. Their feedback is a priceless way to connect the entire delivery team to the customer’s reality
Everyone cares about release management:
- Marketing needs to communicate the value of new functionality
- Design needs to create UI’s and information architectures for feature migration (a la Google’s “do you want to try our new UX?” interface)
- QA needs to validate the release process along with everything else
- Ops needs to enable deployment quality+agility
- Support needs to treat customer education as part of its job
None of this “stretching” means that anyone abandons their particular “depth of skill”. User-centered IT doesn’t result in an amorphous team of interchangeable members. It does mean, though, that interdisciplinary team members appreciate each others’ viewpoints. They consider each other’s needs as part of their own daily activity. They start to ask questions from across the functional ciricle: designers think about resiliency, ops thinks about user experience, and so on, without having to be prodded. In other words, they develop empathy and enthusiasm for each other’s deep skill sets.
Software, delivered as a service, dissolves the boundary between functionality and operability. Customers judge services by their end-to-end experience. In order to deliver customer satisfaction, all parts of the interdisciplinary User-Centered IT spectrum have to align themselves with each other and with the user. T-shaped thinking seems like a natural, if not the only way to accomplish that level of alignment.