Starting a Tech Team Transformation
A horrifying revelation that shocks many companies is the realisation of how ineffective their development teams are. Excessive time spent fixing bugs, inability to support business growth, and being out-iterated by more agile competitors are often the distressing trigger symptoms.
One common reaction is to follow the “we must be agile” hype and bring in an agile consultant expecting a quick fix. As good as a select few consultants may be, for 99% of companies there is no quick fix. Culture, practices and personnel often require radical change.
I’ve had this conversation about improving lagging tech teams what feels like a millions times over the past year. The latest one triggered me to put my thoughts in writing and clarify my thinking — this post is as much for me as it is for you.
In summary, my general recommendation is to create a shared vision of change based on the mission and purpose of the organisation, and then gradually implement it. Without doubt, though, individual circumstances will play a huge factor in any change initiative. In this post I will outline my thinking along with some key details and an example implementation roadmap.
Be prepared for a long journey
Team evolution and transformation is a vast and deep topic. I’ve done my best to create an insightful blog post but there are many opinions, assumptions, and details that I have to had to lightly skim over or completely ignore to keep the size of this document down.
Vision is Fundamental
Priority number one for me is creating a shared vision of what you are trying to achieve.
Without vision I see and hear of teams just following the latest trends like agile, lean, devops and continuous delivery without properly understanding what they mean or what benefits they bring. This is probably why those terms get distorted and commercialised, and is almost certainly why many companies fail to reap the benefits of these genuinely useful concepts.
Another reason for vision is focus. With a clear understanding of the goals and benefits of each improvement, teams can focus on making small logical improvements — focusing only on the one or two most valuable improvements at a time and ensuring they are studiously applied.
I’ve seen some teams who think “we need to improve” and start trying to do everything at once. There’s a great feeling of “hey, we’re getting better”, but really nothing gets properly implemented or finished because there is far too much WIP and far too little focus.
Management Buy-in is Preferable
Collaborating with management to create your vision can be helpful for many reasons. In particular, it’s good to have them on-board with the long-term plan because productivity can often get worse before it gets better when attempting to introduce changes.
If management can appreciate the short-term consequence of change, it’s unlikely they will pull the plug when results initially dip.
More importantly, I would want the vision to express how the changes will benefit the business. So feedback from management and the rest of the business is invaluable in creating the vision.
If it’s not possible to explain how changes will improve the business, I would stop the initiative right there.
In some cases the change initiative may be purely bottom-up; led by one or two enthusiastic developers, but without business buy-in. I would still unquestionably create a vision, even if it is only shared by the tech team. You can always try to win confidence from management and then expand the vision with their input later.
Alan Turing had a vision that took years to fully implement and he had to convince many militant opponents — including those who stood to benefit the most
An Example Vision
Hypothetically, if I was helping to change the tech team of a lagging startup who had reached the scale stage but were spending too much time fire-fighting and not enough time creating value, I would aim to create a structured, progressive vision. Perhaps something like the following:
To achieve our mission of being the world’s most popular commercial online payment system, we need need to deliver more value to our customers, more responsively, and more efficiently. Delivering more value will keep us ahead of our competitors. Delivering more responsively will ensure we deliver what customers want when they want it. And delivering more efficiently will mean that we can keep our costs down and invest more in innovation which is essential to the prosperity of our organisation.
We envision that fostering a company-wide culture of continuous improvement, coupled with continuous delivery of value is essential to achieving our mission; necessitating that our delivery teams be given the freedom to improve and innovate with the acceptance of occasional failure.
We also envision service-orientation being crucial to our teams productivity. Unnecessary dependencies cause distractions and degraded performance. Service-orientation will therefore need to be applied at the team and architecture levels.
Admittedly this vision is a bit generic, and could probably be applied to almost any company. In fairness, though, for most poor-performing tech teams aiming to improve, delivering more frequently and decentralising a top-heavy command-and-control management style will feature prominently.
Importantly, this vision should complement the company’s mission statement and purpose. Ideally it should be based on them. This is why I’ve started the change vision by explaining how it contributes to achieving the organisation’s mission.
Gradual Change
I fully recommend that any change initiative be gradual rather than abrupt. All of the team transformation success stories I’ve been a part of or heard about took the gradual approach.
By taking a gradual approach you cause the least amount of friction; improving one process at a time, or introducing one new idea at a time. Ideally the benefits of each change will be obvious, and people will then increasingly be more receptive and collaborative toward future changes.
Changing one thing at a time also means you upset fewer people at a time. When someone’s responsibilities change, initially they may feel defensive or resistant to the change. Quite often, though, people do come round after a while if you treat them respectfully. Slowly, people then become willing contributors to the change initiative.
I have actually seen this happen. Initially a chaotic process was replaced with a very lightweight scrum-style process of two-week iterations. No estimates, no story points, just a fortnightly catch-up to set priorities. After their initial defensive response, the team quickly became unburdened from the constant harassment they had been used to from a multitude of stakeholders all demanding their urgent priority be worked on. This set a solid platform of trust and buy-in for further improvements.
Conversely, big-bang change initiatives might leave you with an entire company of irate workers, aggrieved that ivory-tower managers have forced perceived unnecessary changes on them. As the Kanban philosophy advises, I recommend respecting existing roles and responsibilities to avoid a civil war.
Identifying Improvements
With a vision of where you want to get to, and a commitment to gradual change, it’s time to start thinking about what can be changed to produce the required improvements.
A combination of top-down improvements led by management and bottom-up changes conducted by delivery teams is characteristic of optimal change initiatives in my experience. Again, this means management buy-in is ideal. But it is not always essential.
Deciding what to change in your organisation is an activity that I recommend is driven by the vision; identify where you are now, where you want to get to, and what you need to do to get there. Then create a roadmap of gradual implementation as I’ll demonstrate a bit later.
Your situation will be unique — many of the improvements you identify may be unique to your change initiative. A lot of changes are almost universal across tech initiatives, though. Here are a list of the ones I expect most companies will need to consider.
I’ve grouped the changes by whether they are top-down (led by management) or bottom-up (led by engineering teams), but the boundaries are very fuzzy. If you can suggest other changes, or have contrary experience, please leave a comment.
Management-led Changes
In general, I find the best way management can help change initiatives is to be open-minded, tolerant, and supportive of alignment. Applying these qualities will motivate, inspire and encourage delivery teams to continually perform their best.
Promote Learning
Management should facilitate constant learning. They should allow and promote time during working hours to be spent on internal presentations, programming exercises, and exploratory learning on topics that are not directly related to what people are currently working on.
In my experience, at least one weekly slot of 2 hours is the minimum that Engineering should be granted to spend collaboratively learning. What Engineering learns about should be their prerogative. I really enjoy people giving internal presentations, and enjoy giving them myself. I also get excited by pair-programming code katas.
Conference tickets, books, and allowances for other training materials should be a given within financial reason. Management should actively encourage people to take advantage of these allowances if they genuinely want to inspire a learning culture because some people are nervous about asking for a book or conference ticket so may not bother.
Empower Capable Personnel
People unwilling to adapt or lacking knowledge of how to create high-performing tech teams cannot be empowered with leadership of a change initiative. It’s up to management to ensure that those able to drive the organisation forward are in a position of influence.
Once those people are able to influence change, they also need to be given the authority on who should be hired and who is incompatible with the direction you want to travel in.
Putting the wrong people in leadership positions or undermining those with the ability to amplify the performance of your delivery teams is probably the biggest indicator of failure.
Understandably, it is hard for non-technical management to know who to trust. They often look at years of experience or programming wizardy, which aren’t always great indicators of ability to lead change.
Increase Alignment
Pushing freedom and responsibility onto engineering teams is how the best companies operate. But it does require that those teams are aligned with business objectives and intent. Therefore, management should create a shared vision of what the business is trying to achieve, and make an effort to communicate the bigger picture.
Examples of practices that increase alignment include:
- The Business Model Canvas
- Impact Mapping
- Value Stream Mapping
- Value Chain Mapping
- Articulating business strategy
- Sharing business metrics and KPIs
Members of delivery teams should not be afraid of initiating improvements in alignment. I’ve worked on teams where we started using the Business Model Canvas and then got management involved afterward.
Be Tolerant of Transient Regressions
Degradations and mishaps will happen with change initiatives. As mentioned earlier, things can get worse before they get better. When a few developers introduce new working practices, it can slow the team down, for example. Management needs to be tolerant in these scenarios and keep a long-term perspective.
The infamous J curve: things often get worse before they get better
If you’re on an engineering team and you know things will get worse before they get better, I would suggest creating a presentation or having a talk with management preparing them for the inevitable decline. There is a lot of empirical data you can gather from blogs and talks to present a compelling business case.
Accept Reduced Control
Some managers just cannot let go of command-and-control dictatorship. They want to choose technologies, they want to dictate engineering practices, they want to decide who is working on what. This directly contradicts most modern change initiatives that want to promote innovation and efficiency.
I wish I had easy answers for competing with command-and-control, but when the problem is power-hungry management, you’ve got a big challenge on your hands. My best suggestion is to keep making small improvements to engineering processes and try to earn credibility. Failing that, I think you either go to upper management, give up trying to improve, or find a new job.
To your advantage, there are many great books, blogs, and talks that you can use to present a compelling case for decentralising power and encouraging practices like servant leadership. I’ve always been lucky enough to have a lot of management buy-in. But I have worked for command-and-control managers where any attempt at change would have been fiercely dismissed.
Engineering-led Changes
Technical people are essential to a technical change initiative. They build the systems, and if they don’t want to improve, your change initiative will be pure comedy. Their motivation is a multiplier of productivity.
Take Advantage of Learning Opportunities
As far as I know, one thing that is consistent amongst the best performing tech teams is that they enjoy software development and are committed to continuous learning.
Some people read books in their spare time. A few talk at conferences. Others like to work on open source projects. And most just like to toy around with new technologies. Regardless, if there is a team full of people who enjoy learning, you have a great chance of improvement if there is encouragement and opportunity for them to improve.
I don’t agree that people should spend all of their spare time devoted to learning. Some people have families and other commitments. As long as they are prepared to learn during working hours, and a small amount of time outside work, that’s good enough in my experience.
Improve Technical Practices
Time spent adding value versus time spent fire-fighting, regression testing, or carrying out non-value adding tasks should be gradually and continually optimised through improvement in engineering practices.
You cannot deploy more frequently or be more responsive to customer needs if the cost of deployment is too high or you are always fixing regressions and bugs.
Deciding what technical practices to employ is where the discussion becomes fuzzy. In my experience TDD, pair-programming, and trunk-based development are some of the best approaches to achieving more frequent releases and improvement in code quality. But I’ll concede the evidence is empirical and subjective.
There’s a tonne of advice available for improving technical practices that improve code quality and enable continuous delivery. So it’s up to the technical teams to decide what they think is best.
Improve Process
I place much of the responsibility for improving process with developers. They can start applying technical practices that enable the vision to be realised. For example, they can start using TDD, pair-programming, and trunk-based development to enable continuous delivery.
Process improvement can be initiated by non-technical people or managers. But engineering people understanding the mechanics of delivering software, I expect them to be actively suggesting the majority of process improvements.
Become More Business and Customer Focused
Delivery teams will need to have a wider appreciation of business goals and intent so that they can self-organise. Ideally some of this change will be management-led, but people in delivery teams should definitely take an interest in learning more about the business.
My suggestion for anyone working in engineering is to learn about business concepts, like business models and value streams. I would also recommend regularly asking yourself what business problem you are solving. And definitely, try spending more time with other people. Ask them what their job involves, and what they are working on.
I finding having a bigger understanding of the end-to-end business processes extremely compelling. It is actionable knowledge that gives me the satisfaction of being able to make a more significant contribution to challenging business problems.
In the Next Post: Creating a Roadmap of Change
Thanks for reading this far in what has been a long and mostly theoretical post. In the next post I will progress into more practical advice by creating an example roadmap showing how a change initiative could be implemented for this example scenario.
If you have any questions, comments, or suggestions about this post, please keep the discussion flowing in the comments. Every company is different, and every company changes of over time meaning that your experience is valuable and your input into this discussion is extremely credible.
