Summary of a book “The Manager’s Dilemma” by Irial O’Farrell

This book talks about the Manager’s qualities that are applicable to a wide variety of cases. It does this by presenting concrete examples that are eye-opening.

The dichotomy between a manager and an engineer is about their approach when unexpected problems arise. People wearing both hats often jump into problem solving mode and are instead advised to be managing. Managers must decide whether they need to be Fix-It champs or to help their team members develop their own problem-solving skills. Irial O’Farrell is the author of this book and an executive coach who advises the second choice. Managers must teach their reports how to handle problems as they surface so that they can focus on their immediate and ongoing managerial tasks. She advises managers on how to coach their team members and delegate problem solving to them.

The key takeaways from this book include:

1.       Most employees can identify problems, but few can solve them

2.       Employees may want the manager to solve the problem, but they must instead be taught how.

3.       Employees must have three reasons to escalate problems to their managers.

4.       Employees must do the necessary groundwork before bringing a problem to their managers.

5.       The manager’s mindset must be to favor managing rather than fixing things.

6.       Managers who become popular for problem solving while leading their teams are at risk of burnout.

7.       Both managers and employees must learn to solve a problem in eight steps.

8.       Both must use the SMART system to achieve their goals

9.       Managers not only empower their employees but also empower themselves to become effective coaches.

When managers are presented with problems, there is a high chance that the employees identified the problem but could not solve it. The manager has a few tradeoffs at this point. They can focus on problem solving to get promoted or they can invest in an unproven approach to empower the team’s problem solving. The difference is in observing the hidden cost of an employee’s inability to solve a problem. Team members may waste their manager’s time or expect the boss to set aside their priorities and ride to the rescue. This creates an impediment in the team’s ability to attain their goal. If the manager and the team discussed and developed problem-solving skills, they ca tackle the current and the next issues themselves. So, a manager must just change the employees expectations for her to solve problems and instead teach them how to do it.

There are other inefficiencies that occur when the proposed approach is not taken. Staff members who rely on their manager to solve the problem never take ownership of the issues they encounter. It may even get worse as others, including the manager, must invest time to pick up where they left off, which hurts the manager’s and the team’s efficiency and productiveness. Coaching fulfils the manager’s responsibilities and contributes to the professional development of their reports.

When employees escalate problems to their supervisor, they might do so because they are lazy, or they have tried unsuccessfully to fix it, or they want to make sure their managers know about it. The first reason is invalid but the remaining two are valid reasons.

Employees must always do the necessary groundwork before bringing a problem to their manager. Before they can coach their employees to solve their own problems, a manager must persuade them to share that goal. The motivation to escalate must be included with the problem presentation. It must also show what approaches for problem solving were attempted and how far they were carried out.

The employees must demonstrate they are not passing the buck as part of “signposting” where he or she indicates that a problem exists but is beyond his or her ability to solve. At this point, the employee wants the manager to ask what needs to be done and how she can help.

Signposting is a clear indicator that the proposed approach is warranted. When coaching takes place, it simultaneously relieves the manager who might be at risk of burnout. The manager must change their mind-set to manage, not fix things. She must focus on her work and responsibilities and not put out fires. This enlightened mindset might be counter-intuitive to their habit that put them in the position of the manager in the first place but it pays over time. Companies do promote managers who solve problems but managers who grow their reports to do the same provide a greater value. This is the “manager’s dilemma”.

A team’s new and improved problem solving resulting from the manager’s coaching may also meet with some resistance initially, but it will provide an opportunity to reduce the escalations in the future. The manager is left with more time and concentration to lead. This is indeed a long-term solution that is better than the tactical problem-solving habit.

There are eight steps to problem solving and these are: 1. Determine the problem, 2. Assess the problem’s reach, 3. Research the problem’s causes, 4. Determine the various options, 5. Evaluate all options. 6. Figure out the ideal solution, 7. Implement this solution, and 8. Review your results.

The SMART system is geared to achieving managerial goals including the coaching of team members to solve their problems. It is a framework for goal-attainment and a performance management tool. A SMART system focuses on Specific goals to achieve, Measurable progress, Attainable goals, Relevant alignments with organization’s objectives and the Timed response to reach the goal.

Coaching is not restricted to team members. Managers must also empower themselves to become effective coaches. Self-awareness is a cornerstone of effective management and leadership.

 

 

 

Azure App Configuration (continued)

 

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Azure App Configuration with the link here. This article elaborates on the best practices with Azure App Configuration.  

Azure App maintains a record of changes made to key-values. This record provides a timeline of key-value changes and allows us to reconstruct the history of any key-value to fall back to a value to an earlier point in this history. The az appconfig revision list command enables us to retrieve all recorded changes to the key-values.

App configuration is particularly helpful for feature management. This is a software development practice that decouples feature release from code deployment and enables quick changes to feature availability on demand. A feature flag can be used to toggle the feature on or off.

Feature flags serve to wrap new functionality under development so that the feature can be shipped even if it is unfinished. It will no longer need to maintain code against multiple development lifecycles. It can be tested in production by limiting access to beta customers. It can also be used to roll out new functionality incrementally in production.  It can also help to disable a feature without rebuilding and redeploying the application. The feature flags can be used to segment a user and deliver a specific set of features to each group. All feature flags used in an application can be externalized. One way to avoid proliferation of key-values is to remove the obsolete ones and promote the feature to current source.

Azure App configurations events enable applications to react to changes in key-values. This eliminates code or expensive and inefficient polling services. Events are pushed through Azure Event Grid to subscribers. Common App configuration event scenarios include refreshing application configuration, triggering deployment or any configuration-oriented workflow. There is a difference between polling mechanisms and event subscriptions where each has its advantage and can be seen with the help of the size of the changes made to the configuration store. When the changes are infrequent, but the scenario requires immediate responsiveness, event-based architecture can be especially efficient.  The publisher and subscribers get just the data that has changed and as soon as the change happens which enables downstream systems to be reactive and multiple subscribers to receive the notifications at once. They are also relieved from implementing anything more than a message handler. There is also the benefit that comes from the scope of the change that is passed down to the subscribers, so they get additional information on just what configuration has changed.  If the changes become frequent, the number of notifications is large leading up to performance bottleneck with variations in the queue size and delays in the messages.  Instead, when the changes span a lot of keys, it is best to get those changes in bulk. A polling mechanism can get changes in batches over time and then process through all those changes. It can even find only the updates that were made from the time of the previous polling.  This enables incremental updates at the destination. Since a polling mechanism is a loop that perpetually finds changes, if any, and applies them to the destination, it can work in the background even as a single worker. A polling mechanism is a read-only operation and therefore it does not need to fetch the data from the store where the configuration is being actively updated. It can even fetch the data from a mirror of the configuration store. Separation of the read-write store from a read-only store helps improve the throughput for the clients that update the configuration store. Read-only access is only for querying purposes and with a store that is dedicated to this purpose, the configuration store can deploy a suitable technology to host the read-only store that can assist with queries. It is recommended that both the source and the destination of the configuration store changes be made better suited to their purpose.

 

 

 

 Azure App Configuration  (continued)

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Azure App Configuration with the link here. This article elaborates on the best practices with Azure App Configuration.  

App Configuration treats all keys stored with it as independent entities. App configurations doesn’t attempt to infer any relationship between the keys. Aggregation is made possible with the help of labels. Application code can perform configuration stacking.

Excessive requests made to App Configuration can result in throttling or overage charges. Requests can be reduced by increasing the refresh timeout, watching a single sentinel key, using Azure Event Grid to receive notifications when configuration changes and spreading requests across multiple app configuration stores. There is an option to bulk import the configuration settings from the current configuration files using either the portal or CLI. The same option can be used to export key-values from app configuration. 

Client applications demonstrate two common risks. First, they use a connection string which is exposed to the public and second, the scale of the requests from client applications can be excessive. It is recommended that a proxy be used instead between the applications and the app configuration store.

Azure App maintains a record of changes made to key-values. This record provides a timeline of key-value changes and allows us to reconstruct the history of any key-value to fall back to a value to an earlier point in this history. The az appconfig revision list command enables us to retrieve all recorded changes to the key-values.

App configuration is particularly helpful for feature management. This is a software development practice that decouples feature release from code deployment and enables quick changes to feature availability on demand. A feature flag can be used to toggle the feature on or off.

Feature flags serves to wrap new functionality under development so that the feature can be shipped even if it is unfinished. It will no longer need to maintain code against multiple development lifecycles. It can be tested in production by limiting access to beta customers. It can also be used to roll out new functionality incrementally in production.  It can also help to disable a feature without rebuilding and redeploying the application. The feature flags can be used to segment a user and deliver a specific set of features to each group. All feature flags used in an application can be externalized. One way to avoid proliferation of key-values is to remove the obsolete ones and promote the feature to current source.

Azure App configurations events enable applications to react to changes in key-values. This eliminates code or expensive and inefficient polling services. Events are pushed through Azure Event Grid to subscribers. Common App configuration event scenarios include refreshing application configuration, triggering deployment or any configuration-oriented workflow.

 Azure App Configuration   

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Azure App Configuration with the link here. This article elaborates on the best practices with Azure App Configuration.  

Application configuration is a regional service. Applications with different configurations per region are encouraged to create separate instances for each region so that they don’t introduce a single point of failure. Multiple configuration stores also help with disaster recovery mitigation. Regions and availability zones in Azure continue to guarantee high availability for this service just like that of other services. Regions are scattered throughout the globe and regions support multiple availability zones.   

There are two options for organizing keys – key prefixes and labels. Key prefixes are the beginning part of keys. A set of keys can be grouped by using the same prefix in their names. Prefixes can have folder paths like separators and qualifications. Keys are what the application code references to retrieve the values of the corresponding settings. Labels are an attribute on keys and they are used to create variants of a key. A version might be an iteration, an environment, or some other contextual information.  

App Configuration treats all keys stored with it as independent entities App configurations don’t attempt to infer any relationship between the keys. Aggregation is made possible with the help of labels. Application code can perform configuration stacking. Any configuration data can be stored such as those that are kept as configuration files or environment variables. For large or sensitive data, it is preferable to store it in other stores or key vaults and save only the references as configuration keys and values. A connection string can be used to access an app configuration store. Managed identities can be used to access the App configuration store.  

Excessive requests made to App Configuration can result in throttling or overage charges. Requests can be reduced by increasing the refresh timeout, watching a single sentinel key, using Azure Event Grid to receive notifications when configuration changes, and spreading requests across multiple app configuration stores. There is an option to bulk import the configuration settings from the current configuration files using either the portal or CLI. The same option can be used to export key values from app configuration. 

Client applications demonstrate two common risks. First, they use a connection string that is exposed to the public, and second, the scale of the requests from client applications can be excessive. It is recommended that a proxy be used instead between the applications and the app configuration store. The proxy service can securely authenticate with the app configuration store without a security issue of leaking the authentication information. App configuration provider libraries enable writing such a proxy service and come with a built-in cache. 

When the configuration is checked in as code in a git repository, it gives the benefits like traceability and approval process for changes. There are tools to deploy this configuration data. App Configuration syncs GitHub action synchronizes the app configuration whenever a pull request is merged to the configuration as a code repository. Azure Dev Ops can include Azure App Configuration push for synchronization which is a pipeline task. Similarly, Azure App configuration uses Azure CLI as part of the CI/CD system to import configuration files. 

 Azure App Configuration

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Microsoft Intune with the link here. The previous article mentioned Microsoft 365 capabilities. This article discusses Azure App Configuration.

This is a service to centrally manage application settings and feature flags. Configuration settings must not be spread out across distributed components of an application or service hosted in the cloud because it can lead to hard-to-troubleshoot errors during an application deployment. App configuration must store all the settings for the application and secure their access in one place.

Unlike zookeeper, which is a co-ordination service with elements from group messaging, shared registers and distributed lock services and provides an interface to guarantee wait-free property and FIFO execution of requests from each client, the Azure App Configuration merely centralizes the configuration as a resource provisioned by a service that can perform access control. This lightweight conversion of configuration to a configuration service is just right to those clients that want to add a key-value or read a key-value from the store.

Azure App Configuration can be deployed using an Azure Resource Manager Template (ARM template) which is a json file that defines the infrastructure and configuration for the project. Azure App Configuration supports hierarchical namespaces, labeling, extensive queries, batch retrieval, specialized management operations, and a feature-management user interface. It is not meant to be a  KeyVault to store secrets and is usually complimentary to a KeyVault in most deployments. It provides hardened security for references to those secrets as configuration key-values.

App Encryption encrypts all key values it holds, and it encrypts network communication. Key name and labels are used as indexes for retrieving configuration data and aren’t encrypted.

It is different from Azure App Settings which allows to define app settings for each App service instance. The settings are passed as environment variables to the application code while the Azure App Configuration allows to define settings that can be shared across multiple applications. The application code accesses these settings through the configuration providers for .NET and Java, Azure SDKs or via REST APIs. Settings can be imported and exported between Azure App Settings and Azure App Configuration.

There’s a limit of 10 KB for a single key-value including its attributes, labels, tags and other metadata. This suffices for most configuration. If a key-value is larger than this, then it can be placed in a cloud store.

Configurations are generally created one store per environment such as development, integration and production environments. This provides the best security isolation.  If we do not need security isolation between environments, we can use labels to differentiate between configuration values.

Free and Standard tiers both provide core functionality, including config settings, feature flags, basic manage              ment operations, metrics and logs but if more than one store is required for a subscription, a standard tier provides unlimited number of stores. Each configuration store in a standard access tier can store up to 10GB and stores history for 30 days. Free tier stores are limited to 1000 requests/day while standard access stores are limited to 30000 requests per hour. Only the standard tier has an SLA and it is 99.9% availability. The first 200,000 requests to a standard tier are free but there is overage charge for requests past the daily allocation.         

 External configuration store pattern 

This pattern is applicable when configuration must be exported out of the application deployment package and into a centralized location. It is useful for sharing configuration data across applications and application instances.  

Changes to configuration should not result in administrative overhead, downtime, or redeployment. It is possible to edit these files to change the application behavior after the application is deployed. It might be challenging to manage configurations across multiple running instances of the application. It can result in instances using different configuration settings across multiple applications. These problems point to a dedicated configuration management system as a solution. 

The configuration management can be stored externally and provided an interface that can be used to quickly and efficiently read and update configuration settings. The type of external store depends on the hosting and runtime environment of the application.  It can be cloud-based storage or a dedicated configuration service or a hosted database or another custom system. 

There are a few things required from this store. First, the interface to read and update must be easy to use. The information must be properly organized. The implementation must authorize the user’s access for configuration protection. It should be flexible to allow storage of multiple versions of the configuration such as deployment, staging, or production. 

In addition, caching will be required for application performance. It depends on the type of backing store used, and the latency of this store. Caching minimizes the impact on application performance and provides fast access. External configuration stores might come with a local cache. 

The following issues and considerations must be tackled when implementing this pattern. 

A backing store must offer acceptable performance, high availability, robustness, and backups. Cloud storage or a configuration platform already come with this approach. The schema of the backing store must allow flexibility for types of information to hold. Multiple versions of settings and rollback are common task. 

The physical capabilities of the backing store also affect usability. If the store must store XML versus JSON, it will require parsing to read settings. Parsing increases the impact on performance. Control over the scope and inheritance of configuration settings will affect the delegation of control. Configuration interface must expose the configuration data in the required formats such as typed values, collections, key-value pairs, and property bags. 

A strict separation between the permissions to read and write configuration might be required and this will be implemented in the configuration store interface. Writing caching configuration data can help address transient connectivity issues. The application deployment pipeline must provide the last known set of configuration values and fallback to an earlier version if it cannot be used. 

Azure Table storage for key-values, Blob storage for hierarchical access, and cosmos DB are some examples for ISettingsStore. An ExternalConfigurationManager class can provide a wrapper over a BlobSettingsStore. This class might use Microsoft Reactive Extensions to publish changes made when the system is running. 

 

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Microsoft Intune with the link here. The previous article mentioned Microsoft 365 capabilities. This article discusses data privacy with Microsoft 365.  

Microsoft 365 for enterprise is a complete, intelligent solution that empowers everyone to be creative and work together securely. It is designed for large organizations, but it can also be used for medium-sized and small businesses that need the most advanced security and productivity capabilities.   

Microsoft 365 scenarios include productivity, collaboration, education, people, and workplace intelligence. It includes services that manage user and device identity, access, compliance, security and helps protect organizations from data leakage or loss.   

An organization maybe subject to regional data privacy regulations that requires protection, management, and provisioning rights and controls over personal information stored in the IT Infrastructure. One of the examples of the data privacy regulation is the General Data Protection Regulation. Failure to comply with this data privacy regulation can result in substantial fines.

Examples of the types of data in the Microsoft 365 include chat sessions in Microsoft Teams, emails in Exchange, and files in SharePoint and OneDrive. The steps to assess risks and to take appropriate actions to protect the data in Microsoft 365 is now discussed in this section. The Microsoft 365 identity, device and threat protection controls for the data privacy needs also provide additional information.

The data privacy capabilities are brought together by several features including the compliance manager which helps to manage regulatory compliance activities, an overall score of the current compliance configuration, and find recommendations for improvement. It is a workflow-based risk assessment tool.

The Microsoft 365 defender for Office 365 helps to protect Microsoft 365 apps and data such as email messages, office documents and collaboration tools from attack.

The sensitivity labels help to classify and protect the organization’s data without hindering the productivity of users and their ability to collaborate.

The data loss and protection capabilities help to detect, warn and block risky, inadvertent or inappropriate sharing of data containing personal information, both internally and externally.

The data retention labels and policies help to implement governance controls and data retention.

The email encryption capability helps to protect personal data by sending and receiving encrypted email messages.

These capabilities help put safeguards in place but continuous monitoring, investigation and response to security incidents will be required, nevertheless.

Microsoft 365 is an identity-based cloud. When the identities are isolated, it becomes a sovereign cloud. The standard Microsoft 365 cloud is used by Enterprise, Academia and even home Office 365 tenants. It has the most features and tools, global availability, and lowest prices. Since it’s the default choice between the clouds, everyone qualifies. The sovereign 365 clouds for geared for advanced data protection both by virtue of isolated identities as well as better controls.