Technology Leaders Be Brave and Focus On Company Culture

Any technology business has to work out from a tech standpoint if they want to be an innovator or follower in the IT industry. It isn't always a simple choice for technology leaders, some companies that become followers will argue they have to do due diligence, they are hindered by internal bureaucracy, have the pressure of daily deliverables to worry about, so they can't afford to be too "bleeding edge" all the time. The more pertinent question is can they afford not to be leading the way? 

Technology leaders may believe that it is in their interest to play it safe, not rock the boat, but in reality there is no such thing as safe. The IT industry is so fast moving, that cracks will begin to appear in existing technology stacks over time, if they aren't invested in, cared for, upgraded, or continuously improved and automated. Standing still in IT will mean the tech that they are using will become dated compared to competitors.

 

One point that becomes apparent when I attend technology conferences and speak to some companies is that they evidently don't have people passionate about technology directing the company. If you look at the most successful companies organisation structures they have a great mix of technical and business people at the helm. So why do so many technology companies in particular have this flaw and why are getting it so wrong? 

To innovate and be successful in the technology industry you need strong leadership at CTO, CIO, Director and Head Of level, that really understand technology and are passionate about continuously improving it, driving it forward, towards common and agreed goals. The worst thing any company can do is not have a clear and concise set of goals at senior management level, as it sends mixed messages to the engineers on the ground that need to deliver on the vision. Engineers can often become caught up in middle management politics which is exhausting for all involved. One joined up message is important, organisations should avoid having departments that act like shadow governments that will pick fault in other teams processes and ways of working. This is a collaboration anti-pattern that will just cause conflict.

 

These technology leadership positions in some companies are all too commonly made up of career managers that may not necessarily have the best understanding of the technology, who believe they have made it, hold a title and power so they are above being challenged on the decisions they make or questioned. There are good ones though, which I have had the pleasure to work with over the years. 

Great technology leaders listen to their staff they don't treat them as disposable commodities. This is where the most common technology leadership faux pas lies, the power of a technology leader lies in their people and engineering talent, a good leader will know when to get out the way and let the team get on with it. Good technology leaders see their job as giving the engineers an environment to prosper and do their job, shielding them from internal politics and blockers.

CTO's, Directors and Heads Of job is not about making low level technology decisions anymore, the role of a technology leader is now more about inspiring a successful culture in the business that allows engineers to innovate and deliver great products to market. Technology leaders need to be open to being challenged, not taking it as a slight, and improving ways of working based on constructive feedback. 

This of course means they need to have a low ego, they will put the company’s interests at the forefront, and not abuse the power they have or be easily offended. Command and control models led by technology leaders is not the way modern companies should be run, it is proven to fail. Tech leaders are in reality too detached from the day to day solution to make accurate technology decisions so this needs to be delegated. 

The engineers the tech leaders have hired should be making the low level technology decisions, tech leaders instead need to focus on the culture, steering the company objectives in the right direction and trusting the engineers to deliver the results. This may be hard for some technology leaders who have come through the engineering ranks, but they need to let go, trust those they have hired to do their jobs and not micro-manage their staff.  

For some technology leaders this means taking a step back, looking at what they are doing and evolving too to adopt this new way of working. Like engineers, technology leaders can learn too by looking at what others are doing in industry, so they too can improve. However, this means actually being open to change and listening, it shouldn't mean looking at what others are doing and using conformational bias to validate what they are already doing. It isn't too late to change and improve as no-one is perfect.

Moving towards an agile approach is fundamentally important too. Milestone based approaches, dictated by managers going in an offsite meeting is anti-agile and doesn't make sense. 10 years ago that may have been acceptable but not today. The software industry is so fast moving that the road map that is documented this month will be out of date next month. This milestone approach should simply make way for agile prototyping using spikes in sprints to evaluate tools and processes, where engineers are trusted to try and test new solutions and show the business value.

Not all prototyped solutions will work, but some will and bring huge business value or speed up ways of working. If an idea doesn't work as expected the engineering team and business will have at least learned a valuable lesson and the engineering team will have improved as a result. The ask of technology leadership from engineers is that their managers trust and support them to make the correct technology decisions. This by no means doesn't mean their decisions can't be questioned or challenged using data. 

The engineers on the ground are normally the most qualified people to make this assessment, so they should be empowered to do so. Management should know when to step aside, this takes bravery though. Including engineers in the decision making processes or even better delegating decision making is very hard for some technology leaders as they see this as power. My argument is that empowering people, is an even greater power.

It is vitally important that any technology decision made by technology leaders or engineers needs to be backed up by statistics, metrics, KPIs and data driven analysis. This is a common theme in DevOps culture, using feedback loops and measuring results to dictate the best ways to continuously improve the solution. 

In the past technology leaders would traditionally make technology decisions based on gut feelings, instinct or even a whim. This really isn't acceptable today, as your competitor will likely be using big data analytics or machine learning, which should be shaping our business decisions and enabling us to become better decision makers, everything must be data driven now.  

If I was a betting man I would bet on data over gut instinct every time. The value of data, stats and measurement cannot be underestimated. In any industry there are the leaders and the followers. The followers will wait until someone like Gartner says that a technology is ready to use before even considering it, by then it is too late as half the industry will have already adopted it. 

Taking weeks or months to deliberate over putting a solution in is frankly not acceptable, if decision making is handed to engineering teams they can evaluate solutions within a few weeks. Managers will take weeks, months or even years evaluating a product or new technology, scared to put it into production encase it breaks. 

Bureaucratic IT processes will outline rigid phases that need to be completed, such as a requirements phase, analysis, with multiple word documents or PowerPoint slides written before finally allowing an engineer to actually evaluate a new tool and see if it proves its worth with real business use cases. Instead this could have been prototyped in a week by an engineer in an agile spike and tested on a subset of use cases using a real world examples to see if the solution was viable. 

My view on this is that these bureaucratic processes are implemented by managers, to quell the pace at which the world around them is moving. So they put in these processes to make it more stagnant environment so they can control everything that is going on, this is done out of fear. Put simply IT management don't need to understand every fine grained detail, that is what they hire and should be empowering and trusting their staff to do. 

Engineers that feel empowered are more likely to be happy and will do their best work, happy staff will also encourage other good people to join the business, therefore raising the benchmark and technical level of the engineers in a company. When you hire good people they will bring good people with them. Poor managers or technology leaders instead will micro-manage staff, hire people less clever than themselves, create an unhappy toxic culture and ultimately the best people will leave the business and move on to companies that empower and trust them.

In the fast paced technology space it is imperative for technology leaders to be brave and encourage innovation and not suppress it. If there are tools or new processes are available that will improve a solution it is imperative that they are implemented straight away. If you wait too long, then the value add or competitive advantage of implementing the solution depreciates and your competitors may implement it first.

The most successful projects are normally when a collection of engineers are given creative freedom to collaborate, share ideas and build something great together, without having to deal with middle management in fighting and corporate politics. This is DevOps in its truest form. 

This is what the DevOps movement is all about, engineers in reality want to work on interesting projects, with cutting edge technologies that allow them to continually improve and couldn't care less about company politics. It is probably true that what most engineers want in life is to be left alone to get on with their job. Gartner calls this mode 2, but they should simply call it the future.