Solving the ‘Hero’ Paradox: Strategies for a Resilient Software Development Culture

In the intricate world of software development, one phenomenon occasionally takes centre stage – the emergence of a “Hero.” This individual swoops in amidst crisis, solving problems that no one else can. On the surface, they may seem like a team’s greatest asset, but a deeper dive often reveals hidden complexities. This article explores the phenomenon of the “Hero” in software development, its implications, and strategies to navigate it effectively.

Understanding the ‘Hero’ Phenomenon

The “Hero” in a software development team often arises due to various motivations. For some, the recognition and affirmation of being a problem-solving champion can be irresistible. Others might be driven by a profound sense of responsibility or the fear of the project spiralling into failure. For a select few, the sheer thrill of problem-solving under pressure is motivation enough.

Whatever the cause, it’s essential to realise that this dynamic, while sometimes beneficial in the short term, often holds hidden perils.

The Impact of the ‘Hero’ Issue on Teams

The “Hero” issue can significantly disrupt team dynamics. With one person shouldering most of the workload and responsibility, a dangerous imbalance can form, leading to increased risk and dependency on a single individual. It’s akin to putting all your eggs in one basket.

More subtly, this dynamic can stifle growth and learning for other team members, who may be relegated to bystander roles. Consider the case of DevOps engineers being the sole knowledge bearers of specific activities for the release, configuration, and setup of non-production environments. It can leave the team in a vulnerable state should the DevOps engineer be unavailable.

The ‘Hero’ Issue: Implications for the Organisation

While the impact of the ‘Hero’ issue on teams is substantial, its repercussions extend to the broader organisation. This single-point dependency creates significant risk, primarily in terms of business continuity.

In the event of the “Hero’s” unexpected absence, whether due to illness, attrition, or even a well-deserved vacation, business processes can grind to a halt. Without their unique knowledge and skills, teams might struggle to maintain the pace of operations, leading to delays, cost overruns, and customer dissatisfaction.

Moreover, the ‘Hero’ issue can inadvertently stifle innovation. If one person continuously resolves crises, the organisation may become over-reliant on their methods, stifling the emergence of fresh ideas and novel approaches. Over time, this can lead to stagnation and reduced competitiveness in the fast-paced world of software development.

Recognising and addressing these risks is paramount for an organisation’s long-term success and sustainability.

Addressing the ‘Hero’ Issue

The first step to mitigating the “Hero” issue lies in fostering a culture of shared responsibility. Encourage all team members to contribute their expertise and partake in problem-solving. However, creating this culture extends beyond just day-to-day activities.

A practical performance framework is an essential tool to combat the ‘Hero’ phenomenon. It’s important to define roles, expectations, and responsibilities clearly. This doesn’t just create transparency; it ensures that the performance of each team member is evaluated on a fair and comprehensive basis rather than the frequency of ‘heroic’ acts.

Next, establish robust knowledge transfer mechanisms. This can be through detailed documentation, pair programming, or regular team meetings to share insights and learnings. Project management strategies can also effectively ensure that workloads are evenly distributed and dependencies are minimised.

Lastly, promoting a culture of continual learning and upskilling within the team can help ensure everyone has the confidence and competence to tackle challenges, reducing the need for a “Hero” to swoop in.

Conclusion

Addressing the “Hero” issue is critical for fostering an inclusive, balanced, and cooperative team culture in software development. While it’s easy to laud the efforts of a singular hero, it’s essential to remember the immense power of collective strength, knowledge, and expertise. After all, software development is a team sport, and its true champions are those teams that work seamlessly together, each member contributing their unique strengths towards a shared vision of success.

Turning Downturns into Opportunities: Leading Software Teams Amid Economic Challenges

In the face of economic hardship, business leaders face unique challenges, and financial services companies are no exception. How can we navigate these turbulent waters, particularly within technology and software engineering? The key lies in fostering a work environment that promotes motivation, creativity, and productivity within your teams.

Understanding the Importance

Tough economic times present a unique set of challenges that test the resilience of businesses, but they also offer opportunities for growth and innovation. In such times, your most vital asset is your team. Here are eight compelling reasons why it’s more important than ever to ensure your teams stay motivated, creative, and productive:

Maintaining Competitive Edge: To survive in a struggling economy, businesses must maintain a competitive edge. This can be achieved through innovative ideas, solutions, and strategies that stem from a motivated, creative, and productive team.
Doing More with Less: Productivity is paramount with potential budget cuts and fewer resources. A motivated team will consistently deliver high-quality work, discovering new efficiencies even under challenging conditions.
Reducing Employee Turnover: The cost of losing a talented team member during economic hardship can be significant. By fostering motivation, you maintain the workforce you’ve invested in and create a loyal, committed team.
Adapting to Change: Tough times often require change. Whether it involves pivoting to new markets, shifting product lines, or adopting new technologies, a motivated and creative team can adapt quickly and effectively.
Employee Well-being: A challenging economy can affect mental health. Motivation and creativity can help boost morale, promote positivity, and improve overall well-being, leading to better work performance.
Customer Satisfaction: A motivated team provides better service, improving customer satisfaction and loyalty – critical factors for business continuity and growth during difficult times.
Recovery Preparation: Companies that nurture their teams during challenging times are better prepared for recovery when the economy improves. They will have a resilient, adaptable workforce ready to seize new opportunities.
Team Cohesion: Team unity can be tested during challenging periods. Maintaining motivation and productivity will likely foster stronger bonds, improving collaboration and team dynamics.

Fostering Motivation, Creativity, and Productivity

So, how can we create an environment that fosters motivation, creativity, and productivity within our teams? Here are ten strategies that can help:

Transparent Communication: Keep your team informed about the company’s current situation, strategy changes, and plans. This understanding is the foundation of trust and motivation.
Set Clear Goals: Provide your team with clear, achievable goals that align with the company’s strategic objectives, giving your employees direction and purpose.
Promote a Culture of Innovation: Encourage new ideas and approaches through brainstorming sessions, hackathons, or innovation challenges. Recognise and reward innovative thinking.
Offer Flexibility: Whenever possible, provide flexible working arrangements. Flexibility can enhance productivity and job satisfaction.
Provide Support: Equip your team with the necessary resources to accomplish their tasks. This could involve training, tools, or emotional support.
Encourage Collaboration: Promote a team-oriented environment where everyone’s ideas are valued and heard.
Provide Regular Feedback: Regularly provide constructive feedback. Recognise efforts and accomplishments, and help your team members improve in areas where they struggle.
Invest in Employee Development: Investing in your employee’s growth and development is essential during tough times. Provide training programs, online learning resources, and opportunities to work on different projects.
Promote Well-being: Encourage physical and mental well-being among your employees. Stress levels may be high during hard times, so encouraging breaks, physical activity, and mindfulness practices can boost morale.
Empower Your Team: Give your team members a sense of ownership over their work. Empower them to make decisions and solve problems independently to boost confidence, job satisfaction, and productivity.

In the face of challenging economic times, the true strength of your organisation comes into sharp focus: your teams. Each crisis, while daunting, provides a unique opportunity to redefine norms, innovate, and grow. By nurturing motivation, creativity, and productivity within your teams, you empower them not just to weather the storm but to harness it. In doing so, they become the engine propelling your organisation forward, transforming hurdles into milestones for future growth and success. As leaders, our role is to light the path, inspire, and let our people be the driving force through the storm towards a brighter horizon.

The Price of Chaos: Balancing Standardisation and Creativity in Software Development

As a software engineer, I once worked for a large organisation that was experiencing continuous growth. However, I found myself in the midst of a chaotic environment where every team was using a different programming language and framework. While the situation seemed exciting initially, it soon became apparent that it was unsustainable. As the number of projects grew, the cost of maintaining all these different technologies began to spiral out of control.

As a solution, the company’s technical leaders decided to standardise on a single programming language and framework across all projects. The benefits were clear: reduced maintenance costs, improved collaboration and better knowledge sharing. It was a no-brainer, right?

Well, not quite. While standardisation can effectively reduce costs and improve delivery speed, it can also harm creativity and innovation. As software engineers, architects and technical leaders, we must know the potential trade-offs and take a measured approach when considering standardisation.

On the one hand, standardisation can help with cost reduction by reducing the number of technologies needing maintenance. But on the other hand, it can also speed up delivery by allowing teams to share knowledge and resources more efficiently. As a result, it can benefit large organisations with many teams working on different projects.

However, standardisation can also stifle creativity and innovation. When we limit ourselves to a single programming language and framework, we may miss out on new ideas and approaches that could lead to project breakthroughs. We may also lose talented engineers who prefer to work with different technologies. As technical leaders, it’s essential to balance standardisation and creativity.

So, what can we do to strike this balance? Here are a few tips:

Consider your organisation’s needs: Every organisation is unique, and there is no one-size-fits-all solution. Consider the size of your organisation, the number of projects you have, and the resources available when deciding whether or not to standardise.
Involve your team in the decision-making process: Your team members are the ones who will be working with the chosen technology daily, so involve them in the decision-making process. It will help ensure that the chosen technology is a good fit for your team and that they are motivated to work with it.
Allow for experimentation and innovation: Even if you choose to standardise, it’s essential to allow for experimentation and innovation. Encourage your team members to try new tools and approaches and be open to new ideas and suggestions.
Keep an eye on emerging technologies: The technology landscape is constantly changing, so keep an eye on emerging technologies that may be relevant to your organisation. Feel free to explore new technologies and incorporate them into your tech stack if they make sense.

In conclusion, standardisation can be an effective way to reduce costs and improve delivery speed, but it can also have a negative impact on creativity and innovation. As software engineers, architects and technical leaders, it’s essential to strike a balance between the two. By considering your organisation’s needs, involving your team in the decision-making process, allowing for experimentation and innovation, and keeping an eye on emerging technologies, you can find the right balance for your team and projects. And one day, you too will find yourself in a situation where you must choose between chaos and standardisation!

9 years in The Bank – lessons learned

I worked at RBS for almost a decade. During my nine years at the bank, I got the opportunity to work with very talented and smart people, and I learned a lot. I want to use this opportunity to summarise some learnings and experiences that I encountered during that time.

Large Organisations are like Big Ships

Large Organisations, like traditional banks, are like big ships, hard to get going, require an enormous amount of energy to move and a long distance to stop. When it finally departs, it’s impossible for it to quickly and swiftly change the direction. The organization is on the constant lookout for problems far into the horizon, to be ready for a direction change maneuver. Finally, if unexpected happens, just like the Titanic, the ship will not be able to avoid the obstacle and will crash into it. Make a mental note as this will impede decisions and choices you’ll have to make.

white cruise ship

Smart people do dumb things – the fallacy of targets

I’ve seen people make irrational decisions, sacrificing Software quality and Customer Experience for the sake of delivering to deadlines. Deadlines quite often self-imposed, making no commercial reason. Those decisions were driven by localized targets, imposed by line managers. Values that the organization pursued, the good of customer was forgotten because the way performance was assessed, was against the targets.
The result was a poor quality software, delivered at a high cost, and at the end had to be scrapped and re-written. Beware of personal targets as those are often in direct opposition to organization vision and objectives.

Smart people do smart things – if you give them some autonomy

I’ve seen and been working in the hugely successful teams. Teams were focused, creative in solving problems and very productive. Motivation was high as well as team satisfaction. What was common for those teams was the autonomy in solving a clearly articulated problem they were given.
When you hire smart people, give them problems to solve, guide them in organization intricacies and help get the resources they need to solve problems but don’t tell them what to do (don’t micromanage).

Shared services for technology don’t work

Creating a team of specialists (for example DataPower developers), co-locating them in one place and offering their skills as services to delivery teams via the ticketing system is a recipe for disaster. Something that makes sense from the accounting point of view doesn’t work for agile teams that are building software. Again, localized targets for Shared Service teams are never aligned with the vision for product teams.

Beware of re-inventing the wheel

I’ve seen the countless amount of open-source frameworks and tools wrapped in a “thin” wrapper, offering the “same” functionality as the original. In reality, central platform teams started with good intention but hardly ever had the time, resources or expertise to deliver the promise. Avoid re-inventing the wheel, instead of wrapping try to integrate and use extension mechanisms.

gray multi spoke wheel leaning on wall

Management and Leadership are two different things

Leaders inspire people to take actions; managers help people to overcome obstacles and deal with distribution of work. It is possible to be a great leader but at the same time a terrible manager, and the other way around as well. During the nine years, I’ve not met a single Great Leader who was a great manager as well. I believe that in a large organization this happens due to a simple lack of time to perform both roles well. Beware of giving Leaders the responsibilities of managers. They might do a mediocre job at both instead of great at one.

Distributed work is hard

Distributing work on a single product creates communication overhead. For example, scaling one team into two teams creates the illusion of doubling productivity. In reality communication, teams synchronization and integration overhead will only yield a fraction of improvement. Introducing new teams, distributed across different location only amplifies the problem reducing improvements further. When scaling for improved productivity, first look into augmenting existing team and fixing all issues in the delivery process to achieve a smooth flow of work.

Working with vendors require much care

Agencies and Consultancies like to deliver software or services on their terms. The typical sales pitch will mention how beneficial it is for the customer and how productive they can be. The only problem is that quite often after the engagement is done, resulting work doesn’t integrate, is build with incompatible or problematic technologies or lacks on quality. When choosing vendors, make sure to have a set of requirements ready, including technologies to use, ways of working (e.g., integrate early and often), engineering practices and quality standards. If you hear questions related to the above list from the vendor, it’s a good sign, but don’t take anything for granted.

Scaling teams to early could backfire

This point is the expansion of the previous mark of Distributing work. If appropriate software architecture, engineering practices, and delivery pipeline are not in place, the resulting product will lack in quality and cohesive solution. Multiple teams will try to isolate itself via designing architecture and solutions that make it possible for them to work in parallel in relative isolation. This time it’s a Convey’s law applicable on the micro level. If you need to move faster, first try to optimize your delivery process before looking into scaling.

Technology is hardly ever a problem

Majority of issues that arise during software development have very little to do with technology and are associated with people relationship and communication problems. Bad communication leads to missed requirements and invalid assumptions. Make sure to validate all the assumptions early and keep revisiting information you gathered. When you have all the requirements, keep on going back to the Product Owner to confirm that what you are building is the right thing. More importantly, if it is still needed.

Finally

Above are just some of the lessons I learned. I will use this knowledge at the new organization I just started work. I think that the above might provoke some thinking for you as well as re-affirm the lessons learned for me.

Start With Why: How Great Leaders Inspire Everyone to Take Action

A couple of months ago I finished reading the book “Start With Why: How Great Leaders Inspire Everyone to Take Action” by Simon Sinek. Simon’s presentation at TED in 2009 was viewed more than 41 million times. He was invited to consult on Leadership for Microsoft and the United Nations.

SWW-Cover-High-Res

I would like to share with you a few observations and thoughts after reading the book.

Manipulation vs Inspiration

Both manipulation and inspiration are methods of making someone take action. Manipulation creates short term result. For example, if a company decides to use manipulation in their sales and marketing approach, like a price reduction, the result will be a temporary increase in sales but it will not build brand loyalty. Try to remember last time when the reduced price of a product made you become loyal to a brand.

On the opposite site of manipulation is the inspiration. Brands that inspire have a loyal group of followers who will always buy a product of said brand. This happens as the followers associate themselves with the values that represent a specific brand.

When it comes to leaders in organizations and companies, those who inspire will benefit from loyal and hard-working employees. So how does one inspire?

The Golden Circle

Simon explains that inspirational leaders and organizations all act and communicate in the same way. He calls that pattern of communication, The Golden Circle.

Golden-Circle

What it means is that communication happens from the inside out, starting with answering the “Why?” question first. Why leaders do what they do and why organizations make what they make. An answer to this simple question communicates the reason for actions, it demonstrates what someone believes in.

People get inspired by others who believe in the same things.

Biological reaction to Why?

As it turns out, humans have a very strong need to feel that they belong. It is one of the most powerful feelings, feeling based on gut. We feel that we would like to belong to a group that shares the same believes as we do as. The feeling of belonging makes us feel safe. We are drawn to organizations and leaders that are good at explaining what they believe in.

The part of the brain responsible for emotions and feelings is called a Limbic Brain. That is not the same part of the brain that is responsible for language. That is why the gut feeling, the feeling of “Just right” is hard to dress in words and explain.

Great organizations are built on the foundations of The Golden Circle and look like a Cone.

GoldenCircle

The Why? element of the cone includes the leader who sets the vision.
Larger, the How? element of the cone contains the next level of senior executives, inspired by Leader, people who know how to bring the vision to life
Finally, the largest part of the organization are the people who bring the vision to life by building the What?

Summary

The book itself is a great, thought-provoking read that I would recommend for anyone. It does explain how and why people are drawn to certain organizations and leaders.

Inspirational organizations and leaders know the answer to the question “why?” and they clearly communicate their beliefs through their actions. Inspiration creates the long-lasting effect of loyal followers or employees.

If you find yourself not having enough time to read the book, have a look at Simon’s TED presentation. It focuses on the core ideas of the book.

Fixing DevOps

I recently posted a one-liner on LinkedIn, that attracted a great deal of interest and thought-provoking discussion.

If I was paid a £1 for every consultancy, company or private contractors who claim to come in and “fix DevOps” for us and then fail, I would be a very rich man 🙂

In light of the comments and queries, I decided to expand on what I mean by Fixing DevOps and failing at it. First, let me start by explaining what was the trigger to write the line.

Devops toolchain

One Cheeky Email

As a Head of Software Engineering I have been targeted by Sales representatives attempting to sell software products and software development services for quite some time now; a few days ago I received yet another email promising to Fix all the DevOps headaches we might have and change our company to become a DevOps Nirvana if only we would to bring them in.

I have been working in the financial sector for 9 years and witnessed a number of times promises that hardly ever been delivered on. I know that my industry colleagues have had similar experiences.

Thus, the above one-liner shared on LinkedIn, was born.

Some problems of large organizations

Historically, the organization I work for had nothing to do with technology. Banks offered financial services for centuries without the use of Software. Computer systems and software were adopted in the 60ties. The technology was used as an aid to business, means of making money easier and faster. Today banks would not exist without IT systems. There is more virtual money in the economy than tangible assets.

In many large organizations, technology is still looked at as an afterthought, the necessary evil that has to be dealt with in the most cost-effective way possible. Latest advances and innovation are hard to introduce. New technologies and processes are adopted at a much slower pace than technology focused organizations like Google or Amazon.

Large and complex organizations can’t exist without modern technology as well as technology makes no sense without their core business. The truth is, both sides have to work together but in reality, the way organizations are constructed prevents it from happening.

Technology is siloed into one organizational unit and business into another, each with its respective leader. Technology becomes a service organization for business. Local goals emerge, driven by local targets resulting in both organization pulling into different directions and the customer finding little to no improvement.

Let’s reiterate some of the DevOps principles at this point:

Focus on delivering value to a user
Thinking big picture – End-to-End product delivery, from inception to delivery and beyond
Never-ending feedback loop on the product, it’s quality and behavior in production
Cross-functional and autonomous teams
Ruthless automation of everything

#BuzzWords to the rescue

I observed the following pattern in the history of DevOps adoption with the involvement of technology leaders at different organizational levels.

A Leader hears a ‘buzzword’: DevOps. Next steps are:

some research into benefits,
multiple visits by DevOps consultancies, referring to case studies within a similar large organization,
a consultancy (or few) comes in to perform DevOps assessment,
a report is produced with information about organizational challenges,
recommendations on how to change and what tools to adopt

Tools become the focus area of proposed improvements as organizational changes are too problematic for A Leader. Consultancy begins the new engagement, ramping up resources and bringing in new tools. The process of “fixing the DevOps” in the organization starts.

A Leader chooses a small area of Organization to roll out new approached and tools. Neither the consultancy nor small area of Organization has enough remit nor possibility to influence any organizational changes, resulting in: consultancies automating a few basic processes, leaving behind a large backlog of future/unfinished work and a hefty bill.

Small, local improvements make little impact in the large organization. The experiment is deemed as a failure and adoption stops (until next Leader arrives or a good sales strategy from different consultancy).

Summary

Many DevOps consultancies are selling The Dream, utilizing template case studies based on the size of targeted organizations, rather than being tailored to individual requirements of said organizations. Challenges posed by organization structure in DevOps adoption are overlooked during sales negotiations. Resulting engagement creates an invalid perception of DevOps as not being fit for purpose, causing more damage than good.

The truth is that for any change to be successful, creating long-lasting effect the initiative has to come out from within, driven by ‘outside the box’ approach.

Let it go

I started my career in software development 30 years ago.

I was 9 years old when my dad bought me my first computer. In post-communistic Poland it didn’t come by easy. After weeks of going through local paper adds, he managed to secure one from a post graduate student. I became a proud owner of Atari 65XE.

As it was just a computer with no persistent storage, I had no other choice but to type in programmes myself. Initially I was copying listings for games and other software from Computer Magazines. After a short while I picked up a book on Basic and learned my first programming language.

Fast-forward few years later I finished my Master Degree in Computer Science and started my first job as a Software Developer. I progressed my career through variety of industries and technologies. At some point, I started to lead a team of developers. It was the first time when I encountered the important learning: becoming a leader means that I needed to “Let it go” . The “It” depends on context and leadership level, which I will come back to later. As well as discovering that I had to “Let things go” I also discovered that I was not very good at it.

Early days

When I started as a young tech lead on a team, I fell into following traps: trying to write code 100% of the time and making all the technical decisions myself.

Coding 100% had undesired side-effect, I was left with no time to think about software architecture and technical vision.

Similarly, trying to make all the technical decision left me becoming a bottle-neck, stretch my time thin, resulting in demotivating the team.

Fast-forward, few years later I was responsible for multiple teams and fell into similar traps: being involved in all the technical decision making, while still trying to write some code and being a developer.

As a result I had no time to write code and became unreliable team member who couldn’t dedicate time towards product delivery. I was also even bigger bottle-neck as now I was stopping multiple teams in progressing. Finally, I was not contributing towards wider organisation architecture and technology strategy as I had no time left for it.

However, recognising an issue is the beginning of a “therapy”. After reading an excellent series of Pat Kua’s articles on Leadership I discovered that I need to “Let go” of my current approach.

But … letting go is never, EVER, easy.

Change

Why is it so hard for humans to accept change and “Let it go”?

It’s because our brains are pre-programmed with recognising patterns. Early human had to fight to survive. Every change in the environment meant unexpected consequences, at time resulting in death. Diverting from common patterns causes stress. We don’t like stress and that is why we are staying in a comfort zone of what we know, as we’ve been doing it before. It feels safe.

Image result for change

How to let go

Starting point is to accept that the change is inevitable. Trying to do all the same things as before plus dealing with new responsibilities is not going to work. You will drop the ball on one of them sooner rather than later.

Next step is to identify what you need to change and “Let go of”. For me change in the tech lead role meant initially that I had to stop coding all the time, learn how to delegate, reserve time to think and visualise technical vision.

After moving to another leadership level I had to learn the language of the business, how to communicate well and delegate even more.

Most importantly I had to accept the fact that I will no longer be the Subject-Matter-Expert in all aspects of the Platform, Products and Architecture but my new responsibilities include driving the vision forward.

I found that talking with my manager about ideas and changes I was introducing helped me a lot. That is why finding yourself a mentor or a coach is helpful during the process.

Finally, there are things you can do to train you brain to accept change easier, it involves cognitive training. Things like brain games, learning new languages or taking up a task that is not in your comfort zone. All of those activities will flex your brain muscles, helping you adjust to new circumstances introduced by change.

Conclusion

Wether it’s leading the team or organisation, leadership is about vision. Organically grown leaders are often falling into traps of sticking to their previous behaviours and patterns, sacrificing their time and forgetting about the vision.

We need to “Let go” of the old habits and accept the change, resulting in a clear vision for team/organisation to follow and more productive and efficient teams.