Technology companies that push the boundaries of product innovation — like Apple, Microsoft, Google, Yahoo and Amazon — share a commonality: world-class engineering teams. But you don’t have to be a tech behemoth to make big impacts within your own industry.
The formula for building a team of highly motivated engineers that can get accessible and scalable products to market quickly and efficiently can be had by all. Over the course of my career, running large engineering teams, I have experienced the good (products delivered on-time against a well-defined commercial and technical strategy), the bad (internally driven projects failing to deliver commercial value) and the ugly (products contractually sold prior to build with no involvement from technology). So, what does it take to become "world-class?" Here’s my guide:
Clearly, you have to hire people with the right skills and the right mentality, but that isn’t sufficient. They must also be highly motivated and engaged. People do their best work when they are given the freedom to do the type of work that they really care about and enjoy. The steps to achieving this can be found in Daniel Pink’s "Autonomy, Mastery and Purpose Framework" — a framework that I have often used when leading my own teams.
According to Pink, autonomy motivates people to think creatively without conforming to strict workplace rules. By rethinking traditional ideas of control — regular office hours, dress codes, etc. — companies can increase staff autonomy, build trust and improve innovation and creativity. For me, autonomy is where engineering teams are given outcomes and constraints. The teams are then empowered to come up with their own approach, which they are trusted to deliver.
Pink's definition of mastery is the desire to improve. If people are motivated by mastery, they'll likely see their potential as being unlimited and will constantly seek to improve their skills through learning and practice. For me, mastery is where teams are encouraged to continually improve. Building a continual improvement mindset and giving the teams space to implement improvements enables them to master their trade.
Pink says that those who believe that they are working toward something larger and more important than themselves are often the most hard-working, productive and engaged. Purpose, for me, is where there is a clear strategy and vision that teams can align to. Organizations that ensure the business strategy is clear — and that the technology function is critical to its success — create an excellent environment where everyone's purpose is clear.
Along with autonomy, mastery and purpose, and I’d like to add one more component which I think is critically important to fostering motivation and engagement: Communication. Frequent and transparent communication throughout all levels of the organization — where the company's vision is reiterated, the team plans are clear and achievement is recognized — is needed to drive engagement.
At OAG, we've naturally implemented Pink’s framework, and as a result, we have world-class levels of low attrition from a delivery-focused technology team that my organization has high confidence in.
So, you have highly motivated and engaged people working on your tech and engineering teams. Now what? They need repeatable, fail-fast processes to power innovation and to deliver reliable, fast product increments.
A critical process to driving success within tech and engineering teams is CALMS, a framework coined by Jez Humble. CALMS (culture, automation, lean, measurement and sharing) assesses a company's ability to adopt DevOps processes and measure success during a DevOps transformation.
Modern engineering teams require collaboration across a range of different stakeholders. A collaborative, open and high trust culture among product managers, engineers and IT operations is required to enable this to work. High trust = speed!
Unnecessary human intervention must be removed to produce repeatable processes. If your team is doing manual work on a periodic basis, human error will inevitably be introduced and delay the flow of the team’s build processes, tests and deployments.
This is all about the flow of the work. Your teams should break up its work into small chunks that can be delivered quickly. Further, you want to minimize WIP (the work the team has in progress at any one time). Small, frequent changes reduce the time to find and resolve any unexpected issues with your new software.
How do you know if your improvements add value if you can't measure them? You must understand what it takes your team to deliver on their commitments, their deployment frequency (daily, weekly, monthly), and their MTTR (mean time to repair) — i.e., when the system fails, how long does it take to restore service?
This enables teams to understand what success looks like and how they must work together to succeed. It also supports a transparent working environment where ADRs (architectural decision records) are available for historic decision-making references and "blameless postmortems" are available for teams to learn from inevitable failures. Transparency drives trust.
At OAG we've aligned naturally with CALMS. My advice to other tech organizations who want to do the same is to, first, make automation key to everything you do. Second, empower your teams. Third, hold them accountable with a regular cadence of measurement. Finally, use the derived metrics to drive an improvement culture. Clearly, this takes a lot of focus, but you will produce a high-performing tech organization by making this "the way that things are done."
There's quite an overlap between the DevOps CALMS mentality and Pink's intrinsic motivation framework. If you embrace the sentiment behind these structures and use them as a guiding light for your team dynamics, you'll be well on your way to building a "world-class" engineering team.
This article was originally published on 13 May 2021 by Forbes Technology Council.