New Managers Need a Philosophy About How They’ll Lead – Carol A. Walker 

Being promoted to manager is a good sign you’ve been successful to date — however,  the road from this point forward gets trickier to navigate. Your job is no longer just about getting the work done. You’re more likely now to find yourself juggling conflicting demands, delivering difficult messages, and addressing performance problems. While there is no guidebook of straightforward answers to your new challenges, having a clear philosophy can provide a firm foundation from which to.

With respect to your career, a philosophy is simply a cohesive way of thinking about your role. Very few people take the time to establish one. Most managers live in a reactive mode, responding to issues based on gut feelings, past experiences, and examples set by others. The success or failure of this approach is often determined by your temperament (some people are naturally more gifted managers than others) and the caliber of your role models—two factors largely out of your control. Whether you’ve been lucky in these areas or not, having a core philosophy can help guide you through the day-to-day and the job’s tougher moments.

The idea of “servant leadership” is a great place for new managers to start. Robert Greenleaf coined the term 35 years ago, but the concept is still vital and empowering. Granted, “servant” doesn’t sound nearly as powerful as “boss,” but it has the potential to deliver far more of what most of us are really after: influence.  The reason is simple. When you have a servant mentality, it’s not about you. Removing self-interest and personal glory from your motivation on the job is the single most important thing you can do to inspire trust. When you focus first on the success of your organization and your team, it comes through clearly. You ask more questions, listen more carefully, and actively value others’ needs and contributions. The result is more thoughtful, balanced decisions. People who become known for inclusiveness and smart decisions tend to develop influence far more consistently than those who believe they have all the answers.

Servant leadership is most powerful when applied to managing employees. The first step in embracing this mindset is to stop thinking that your employees work for you. Instead, hold onto the idea that they work for the organization and for themselves. Your role as servant is to facilitate the relationship between each employee and the organization. Ask yourself, “What will it take for this employee to be successful in this relationship?” And, “What does the organization need to provide in order to hold up its end of the bargain?” When these questions drive your thinking, you advance both parties’ interests. (The same principles apply to managing products, supply chains, and customer relationships, but we’ll keep our focus on employees here.)

Does servant leadership prohibit telling people what to do or correcting their behavior? On the contrary, it means that you must do these things to facilitate an individual’s success within the organization. The key is that your mind is in “servant mode” when you perform the daily tasks of management.

For instance, assigning work should be a thoughtful process that balances business goals with an individual’s interest, skills, and development needs. Not every routine task has to be so thoroughly considered. But whenever significant assignments are made, putting them into context maximizes their impact. An employee who understands why she has been asked to do something is far more likely to assume true ownership for the assignment. When she owns it, you become more guide than director. You ask how you can support her and how she would like to report progress rather than tell her these things. An employee who believes her boss understands her strengths, values her input, and encourages her growth is likely to stick around for the long-term.

Clearly, the servant approach to assigning tasks requires more thought and preparation than simply dishing them out. It takes time. But remember that you are actually multitasking—you are making sure the work gets done while simultaneously strengthening the individual’s relationship with the organization.

Adopting the servant philosophy should also make it easier to provide corrective feedback. You are merely a facilitator, and facilitators aren’t angry, frustrated, or resentful when they deliver feedback, because it isn’t about them—it’s about the relationship between the two other parties. For that reason, exercising the servant frame of mind makes development conversations feel less personal. You aren’t disappointed in your employee’s actions; you are simply explaining how they get in the way of what he’s trying to accomplish for himself and the organization. When your only agenda is setting someone else up for success, your words tend to be received more openly. True upset happens when either party’s interests are allowed to suffer over time without intervention. It must be the manager’s primary concern to balance those interests.

By definition, developing a reputation takes time. However, when you are consistent with the servant approach, people know what to expect from you and trust ensues. Trust, combined with the smart, inclusive decision-making discussed earlier is a surefire way of gaining influence.

We’ve just scratched the surface of the many challenges that you will confront as a first-time manager. There is simply no way to anticipate them all. But a core servant leadership philosophy will provide critical guideposts to help you manage in real time. Whatever your temperament, a serving mindset will keep you out of the reactive and self-protective patterns that can impede your success. Servant leadership may not appeal to those who are attracted to a more traditional idea of power, but it should be the choice of those interested in influence and results.

Risk Management in a Digital Business

I had the pleasure to have had a 6 months sting with a digital tech startup – it looks and feels very different from the previous company I was in. From the size, people, to the culture, operational priorities, they are all different. But there are common things below the surface– revenue bottom line, customer value as a key driver and back office support functions such as HR, Finance. What is fundamentally different is the pace it operates, its responsiveness, use of data and the capacity to transform concepts from ideas to products at an amazing speed (GTM).

Managing two priorities

The very nature of digital means that you constantly managing two competing priorities – constant and speedy innovation vs. the achievement of long term strategy – or as a respected CIO put it in analogy – growth pain of a teenager wanting to party hard but also grow up. While in traditional environment, balancing tactical and strategic decisions is not a new concept, in the new digital age, this must be done ‘on the fly’. Much of the short-term innovation (tacticals) actually helps solidify/confirm/reinforce the longer-term strategy and the ability to quickly pivot becomes a key ingredient for success.

This is where aspects of Agile and Lean methodology I believe is the underlying factor. And I believe it’s an irreversible trend. It helps to deal with this constant change and being agile becomes a way of thinking and way of work, rather than a simple project management methodology.

See my previous posts on How does risk management stay relevant in a fast-evolving digital world? And How does risk management stay relevant in a fast-evolving digital world? (Continued)

Trial and error and de-risk

Underneath all great innovations is a common thread, which is the meeting of a demand of a customer. Because customer needs change all the time, the ability to innovate must adapt to it. What drives the success of a tech company is this concept of minimum viable product – being able to deliver incrementally and quickly, but also shut down those not meeting the needs. Forget about elaborate planning, business casing, projection etc, get the hands dirty and trial, test, de-risk, iterate and refine.

Not all projects survive because not all of them were good ideas to start with. Baby steps and thin slices make achieving something tangible easier, make decision making easier and worst case it makes the failure feel less painful and costly. The company I was in had a half yearly ‘hack days’ where all employees are encouraged to down tools and collaborate with anyone they like and work on a mini project for whatever the problem they feel passionate about solving. The end result is one that surpasses all expectations – lots of great ideas, lots of happy employees, lots of team building and lots of commercialised products.

Agile culture and risk culture

Arguably building this sort of culture is harder to do than building a risk-aware culture – yet I believe a collaborative, transparent and agile culture will embrace concept such as risk just like anything else. I’d go further to say that digital environment will foster a risk-aware culture faster and more effective than traditional management environment.

The culture that fosters innovation ultimately is the culture that allows for experimentation and failure. Whilst superficially it sounds not so rosy and presents challenges to risk professionals – because failures actually can result from a lack of risk consideration and can mean the eventuation of the risk you want to prevent at the first place, I believe it can be managed because the ingredient of a risk aware culture is there – collaboration, transparency, value driven. In this sort of environment, its more likely that whatever the decision made is actually a risk-informed decision and the team is conscious of the risks involved in getting down to the path we chose.

Cross-functional Collaboration

Another driver behind digital success comes from a deep-rooted concept that is cross-functional collaboration. Sales, marketing, finance and aspects of IT all become part of an extended team. To bring all these personalities together is a monumental challenge. The tech teams are not motivated nor challenged in the same way that Sales or Marketing teams. I had been to standups, inceptions, townhalls and retros and everyone has something different to contribute. How does risk present itself amongst all of these dynamic people remains an interesting challenge for me. But one thing for sure. Risk people need to be physically present, and only being present you can demonstrate that you are trying to understand the problem at hand, the thinking, the approach and the solution adopted. From there, maybe a well-thought out risk advice can be provided.

Different dynamics in IT

I also happen to have spent a lot time with our IT community. My take is that IT has a totally different definition in a digital environment. Using agile, the boundary between IT and business is ever blurred. IT is ‘actually’ the enabler to execution of the strategy. Nowhere else I saw IT being so value driven and collaborate with the rest of the business community so seamlessly. Via delivery leads and technical leads, real collaboration happen and everyone focus on one common delivery goal – customer.

In many businesses the IT team are purely infrastructure and or operations as a service function. However in digitally centric businesses the IT teams are your conduits to execution. And, much like how sales and marketing staff are evolving so are these IT teams. Even within IT community itself, evolution occurs as we speak, concepts such as scaled agile framework, scrum, lean, devOps, extreme programming are being trialled, adapted and matured. Logical organisation structure such as squad, tribe and guild are created to allow for one thing – better collaboration.


Digital is the buzz word now and disruption to the existing business is what most fear. As many embark on the digital transformation journey, risk management can play a unique role in making sure the end objective is achieved. Having a risk view to the whole digital landscape provides a balanced view on the pros and cons. Importantly, it ensures the adoption of a technology or digital initiative is not made independent of the benefit it can provide. A conversation (risk assessment) on the ‘value’ from moving to digital can save millions on what otherwise would have been spent on just another ‘feel good’ solution. Technology is an enabler, risk professionals need to remain objective and inform management that the customers forever sit at the heart of the solution and technology is there as merely a conduit.

Incident Management and Agile Thinking

I recently had a very interesting conversation with a respected friend who works in incident management. The company in question is a giant in a traditional sector with mostly established and linear structure and processes. The company realises and is directly facing the impact of digital revolution and is gradually transforming itself to be prepared.

However, due to its long history, size and a diverse set of business areas, this transformation is only gaining traction after 3 or so years. Initiatives such as process redesign and streamlining became norm, cultural changes on unified purpose and shared values were introduced. Parts of IT and Operations even attempted to bring agile methodology into the scene. Not to mention the company also flexes its muscles and took over a handful of tech startups for both vertical and horizontal integration.


To be perfectly honest, I have rudimentary knowledge about incident management and operations management overall (though I completed ITIL greenbelt years ago) but I summarised some key attributes as below:

  • Its extremely time sensitive – when an incident occurs, standby teams kick in to respond, restore and recover, all along keeping the internal and external (if necessary) communication going to ensure impacted stakeholders are ‘in the know’
  • Its extremely unpredictable – incidents may occur from anywhere in the company’s value chain. Sometimes the collateral damage or flow on effect, an incident that occurred outside of the company’s remit may still be considered significant to warrant actions
  • Its extremely demanding – in a complex environment, the process needed to respond to, restore and recover from an incident must be coordinated across different stakeholder teams in different functions and perhaps in different geographical locations. This collaboration and coordination requires years of team building, finetuning processes, clear roles and responsibilities through wargaming and tackling real life events
  • Its extremely long-tailed as a process – from initial incident detection, severity assessment and escalation criteria, to allocated response, containment and communication, to incident closure, root cause analysis and problem fixing. A properly set up incident management is usually the thread connecting an otherwise disjointed set of functions
  • Its extremely data rich – what went wrong says a lot about the integrity and robustness of a process. The nature and volume of incidents is a great source for risk assessment, business cases, cost and benefit analysis and ultimately decision making on what, why and how to fix a problem

As our conversation went along, the agile-inspired part of me took over and joined force with my risk management brain. We started thinking and exploring how potentially agile and agile thinking could help the incident management team to be better at what they do. Here are some of it:

  1. A core principle of agile methodologies is to limit ‘work in progress’. Teams will agree to take on a small subset of work from the pipeline within a timeboxed period. By limiting the teams focus and attention on what is most important you enable them to complete work to the appropriate quality standards. In incident management context, its usually about completing the root cause analysis and introducing permanent fixes so similar incident do not reoccur.
  2. Another similar agile concept is to focus on the most important task at hand. Highly relevant to the incident management that had to reprioritise constantly as new incidents come to hand. The team can gain a lot of focus by understanding the pipeline. Where the incidents come from? How does it arrive in the team. Visualise it by using agile tool like leankit or trello can help identify which items are the most important and challenge the team to focus on and finish those items. By reducing the scope of work could result in a change in behaviour, delivery time and quality.
  3. Another great attribute of agile is empowerment of the team that is usually self-organised and cross functional. It may be an easy concept to adopt as the team is already embracive to the idea of working collaboratively across the teams. They understand that it is usually the key in successfully dealing with an incident
  4. An extension of across team collaboration is the concept of DevOps – continuous and dynamic change management. The company still operates under the traditional change management model where limited release windows are predetermined and production is locked down otherwise. Dedicated management layers of testing and approval points must be passed before a release becomes possible. Historic data confirms that this model is a big pain point – significant spike in incident volume follows a release window. DevOps could perhaps change this paradigm or at least improve the situation but I agree it sits beyond the remit of incident management team and requires a wholesale change in how IT operations (software development, change management, testing, service management) works.
  5. Agile teams work with the principle that plans will change; that the understanding about the work becomes better as we go along and that no amount of planning really prepares us for the road ahead. It is also true for incident management too. By working in iterations and deliver incremental values, an incident team can handle distractions and uncertainties associated with investigations much better. Hypothesis and assumptions made at the beginning are normally wrong and being flexible in delivering small fixes can help the team in solving the problem in piecemeal fashion and bring together business stakeholders along the journey. For the teams this might mean short term focus on a set of metric goals to solve a particular business problem. Just having the routine of sitting with the business and reviewing priorities is a great first step.
  6. Adopting the concept of the “Definition of Done” for common activities. Not an operations manual that no one will ever read but a collection of one-page definitions of what it means to be done with regard to a problem ticket. Make the definition of done visible and easy to use, incident managers will know when they are finished with a piece of work before moving on.
  7. The best architectures, requirements, and designs emerge from self-organizing teams. Teams that are not controlled but enabled. Teams that trust each other enough to have passionate debate and disagreement without destroying the teams culture. The worst experience for an incident manager would be presented with a piece of work that has no scope for flexibility or creativity, and worst of all to be told how long it will take. Imagine an incident team that is self-organising within the constraints of the organisation. They receive requirements that describe the incident (why), the ideal acceptance criteria (what) and they, as a team, determine the solution (how). With that trust, the team know they have spare capacity for more work and they pull work into their queue.
  8. Short time-boxes focus teams on an objective they have to meet – particularly in this highly unpredictable incident environment, the most valued attribute of the incident team may not just lie in the velocity or the volume of work, or the number of fixes they delivered? It may just be that the rest of the organisations really appreciates the predictability introduced by working in set time-boxes, or sprints, so they know incidents and their fixes are being taken care of.

I’d love to hear people who work in IT Operations, service desks, incident and problem management and engineering who can compare the way they work currently against these ideas – all of which are simple and cheap to implement. If you have experiences in overlaying agile to existing service operations, even better – please share.

Ultimately the ideas of focus, alignment, self-organisation and predictable rhythm promotes a culture of learning – about the work the team handles, about how the team performs and how the team interacts with the business. What are your thoughts?

#agile, #agile thinking, #incident management, #service management, #ITIL, #devops, #collaboration, #Rispeak