BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Engineering Culture Revived: The Key to Digital Transformation

Engineering Culture Revived: The Key to Digital Transformation

Bookmarks

Key Takeaways

  • Organisations in all sectors must excel in Digital to compete
  • Continuous renewal / transformation is becoming business as usual
  • Software engineering teams must take the initiative on leading improvements
  • Top-down driven interventions ruin engineering culture
  • It’s time to revive the core practices underpinning successful software for sustainable change

Teams can create their own environment for sustainable development which enables innovative insights into what and how to deliver, argued Finbarr Joy. Team managers must anticipate the need for continuous improvement and renewal, or else face the interference of a ’top-down’ driven ‘digital transformation’ that frustrates software engineering practice . It’s time for teams to reclaim the practice of software engineering.

Finbarr Joy, group CTO at Superbet, spoke about engineering culture at QCon London 2018. Previously InfoQ published a summary of the morning sessions and a summary of the afternoon sessions from the Building Great Engineering Cultures and Organizations track.

InfoQ interviewed Joy about how ‘top-down-driven- transformation’ projects can hamper the engineering culture, how the engineering culture look at Superbet, how software development teams can embed an engineering culture, and what managers can do to support and improve the engineering culture in their organization.

InfoQ: You spoke about how ‘top-down-driven- transformation’ projects can hamper the engineering culture. Can you elaborate?

Finbarr Joy: As the scale and pace of ‘digital’ demand has swept across industries, and as many (especially large corporates) have struggled to keep up, we’re seeing a ‘parallel universe’ of techniques/ tools and vocabularies emerge from those drafted in to help by the executive (all too often, management consultants/ analysts). While some of their interventions have their roots in software engineering good practice (e.g. agile), their interpretation/ implementation has become so distanced from practical engineering as to render them pointless. In particular, I have seen a market emerge for ‘off the shelf’ frameworks/ techniques that the corporate buyer desires as a ‘quick fix’ for their ‘IT woes’ and that unfortunately a burgeoning 3rd party consulting market is only too keen to cultivate.

The exercises that result from this are typically focused on large scale process adoption – colleagues are drafted to ‘certification’ classes in bulk, and the focus is very much on the ‘ceremony’ of the process rather than the improvement of customer and software outcomes.

As we saw from the show of hands at QCon, many organisations are now in their 2nd/ 3rd wave of ‘digital transformation’ and having burned their ‘change budget’ (thanks Kevin Goldsmith for that coining!), teams are no longer engaged to consider continuous improvement through (for instance) agile. Over the past few years I have met several teams for whom agile was now anathema, based on their experiences of having pointless tasks and ceremonies imposed, only for another set of equally arbitrary tasks and ceremonies imposed within months after as the agile ‘flavour’ / fashion changed (and rarely, if ever, any genuine change in the business process / culture).

Another common intervention is the establishment of ‘innovation labs’ as incubators of the organisations’ ‘digital response’. The rationale for this is often that “we can’t expect the core business to change overnight”, but is also a preservation of the status quo for entities that are expected to maintain / improve quarterly performance as shareholders see it – no risks can be taken with core business/ product propositions. This quarantines ‘interesting’ development within a safe ‘sandpit’ of the organisation, but leaves the core business to stagnate while also preventing the cultivation of a thriving engineering culture through innovation as a core responsibility for all.  

In summary, while many organisations under transformation broadcast the imperative for ‘autonomous teams’, innovation and software as core business, very few sponsor and ‘walk the walk’ for the true ‘bottom up’ changes this requires (depending on which analysis you believe, anything between 50 – 90% of transformations fail); the outcome is demotivated teams and a failing engineering culture. 

InfoQ: How does the engineering culture look at Superbet?

Joy: We’re doing all we can to hold on to a natural-born ‘entrepreneurial’ spirit while accelerating growth / establishing scalability. In just over eight years, Superbet has established a market-leading position in Central and Eastern Europe for Retail betting; meanwhile, over the last year we have invested heavily in the establishment of a ‘dot com’ team that will launch us globally online.  Along the way, we have embedded many acquisitions and so we have quite a ‘melting pot’ of nationalities and practices, but the entrepreneurial flair runs core through all. So for instance, our Slovakian Payment System team operates completely distinctly from our UK Pricing / Trading products team, but both came to our business with an existing implementation-driven approach to market evolution: the capability to test and learn built in as core practice.

 As we evolve our teams we are taking care to establish the right ‘conditions’ for engineering culture from the start; so for instance, working to a business outcome (“need to launch in territory by date X”), it is the team that decides HOW this will be achieved.  The teams are also responsible for recruitment such that new team members are selected by the team (rather than ‘dropped in’ by an external HR ‘recruitment’ process).  Finally, the teams have significant remit for the pursuit of innovation and we are seeing ground-breaking initiatives emerge around Open Source, Machine Learning and Event Sourcing architectures as a result.

InfoQ: How can software development teams embed an engineering culture?

Joy: I think it’s time for teams to reclaim the practice of software engineering. In particular, I think most teams underestimate the level of discretion they actually have to establish the environment for a healthy engineering culture to thrive.

For instance, when faced with a challenging deadline, how often do we see teams volunteering to sacrifice test effort – or creating hacks/ technical debt without specifically trading off? The next time a piece of demand comes in, don’t volunteer hacks (unless specifically traded off), but state the estimate such that the best recourse to reduce the risk is to revisit the business scope – it is very rare that EVERYTHING being asked for is completely necessary – and this is a far more fruitful conversation that also segues into incremental delivery (“instead of all of that, let’s deliver piece a first and see if it gives us a useful start before progressing all the rest”).

By establishing such patterns, the team creates an environment for sustainable development that then underpins the generation of innovative insights into what and how to deliver.

Similarly, I think teams underestimate their scope for ‘self-organisation’; for instance, team members can stand up and be counted – mobilise colleagues together around common interests to at least form ‘communities of practice’, whether the organisation is sponsoring formal re-structuring or not. Finally, teams can proactively define the characteristics that make a difference when recruiting new team members and take more ownership of this versus ‘factory’ HR processes. Under this model the team will usually benchmark richer characteristics, such as how a prospective member deals with specific engineering problems or how they provide support to colleagues, filling blanks they didn’t even previously perceive existed (which would not be picked up by the blunt corporate ‘skills list’ or ‘experience level’ filters).

All of these sustain better engineering environments / allow culture to develop, but also create highly visible signals of change and continuous improvement – hence the team is less prone to arbitrary top-down change, driven through ignorance of what good looks like.

InfoQ: What can managers do to support and improve the engineering culture in their organization?

Joy: I would acknowledge that a lot of what I describe above is a world of fantasy for many teams that find themselves in an environment that is anything but supportive. This is where the manager must intervene. By anyone’s interpretation, the world has clearly changed – the trajectory for software capability as engine of commercial success is set, and it is the manager’s responsibility to begin that education process with her business peers, ensuring that the techniques/ practices and principles are understood to be rooted in good engineering practice that the organisation must now rally behind.

While the new terminology of ‘digital’ can be beguiling to the fascinated executive, giddy with excitement to ‘disrupt or be disrupted’, it should be recognised that good teams, practiced in software delivery, already know this stuff –even the Bell Labs’ Unix Timesharing Systems documentation from 1978 articulates:

  1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
  2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
  3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
  4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

Reference: Unix philosophy on Wikipedia.

Swap ‘service’ for ‘program’ above and you have pretty much the most contemporary advice on microservices/ cloud, agile, and devops – there really is ‘nothing new under the sun’!

Despite previous mis-placed interventions from ‘on high’, team managers must not let the ‘white noise’ of digital hysteria deflect them from doing the right thing in establishing the best environment for their teams to do themselves justice, deliver delight for their customers and cultivate the culture that means engineering thrives:

  • Establish a ‘mission’ / purpose that unites the team behind a core challenge and provides the ‘guiding light’ for more autonomous working.
  • Walk the walk of behaviours that sustain effective team interactions: mutual respect, proactive communications, and constructive challenge.
  • Sponsoring ‘headroom’ for innovation – if you’re not innovating, why write software at all (in a SaaS world especially there is no domain for which standard business workflow isn’t available ‘off the shelf’).
  • Remove all external team/ environment impediments that prevent the team from releasing software ‘on demand’ (no external dependencies/ more ‘honest’ resource prioritisation to ensure full lifecycle coverage is available within the team).
  • Ensure the team gets the benefit of regular feedback to prevent ‘death march’ drudgery – agreement with the business for incremental / proof-driven evolution of the solution.
  • Sponsor the sustenance of ‘refactor’ time as a standard part of every release – enable the team to keep on top of technical debt/ keeping changes manageable, and not having to wrestle with a ‘big ball of mud’ one day (also plays into prioritising better).

With the compound technology innovations emerging from cloud, machine learning, ‘mixed’ reality, voice activated, and crypto-currency initiatives, there has never been a better time to be building software. Reclaim the core practices for your team and take your opportunity to leapfrog the future.

About the Interviewee

Finbarr Joy is Group CTO for Superbet, a new entrant into the online gaming industry. His prior roles have included stints driving technology transformation at global operators such as BT, William Hill and Lebara, and he also co-founded and ran a UK-wide e-commerce software development company through the 2000’s. Joy’s early experiences included two years with Netscape, as a member of the team who brought the Internet to the world, and established the enduring model for digital innovation.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT