Any advice for a new software leader looking to ID blind spots about their organization?

EngineeringNew to Role
211 viewscircle icon1 Upvotecircle icon2 Comments
Sort by:
Strategic Banking IT advisor in Banking2 days ago

Blind spots could be multiple.   Just to name 2:

1. Knowledge of the actual applications portfolio (health, obsolescence, rationalization)
- With a TIME classification
- Identifying the jewels of the Crown system that must received more attention

2. Knowledge of the real operational costs of each and every applications
- To take better decision regarding maintenance and investments 

Director of Innovation in Healthcare and Biotech3 days ago

First, start with a Stakeholder map. Note everyone associated with value delivery in the org. Then set up time with people at all levels, intentionally looking to build trust through candid discussion. Obviously, how you approach this depends on the depth of relationships you've already established. 

There's a really interesting tool we use often called the Energy Map. It's meant to ensure shared focus among a group discussing the challenges and opportunities that exist in that team and its processes. I'd recommend considering the use of this tool with groups, both project teams and larger, cross-functional groups. 

https://verusglobal.com/energymap/

Content you might like

Are AI coding assistants actually making your software developers more productive?

Yes83%

Somewhat11%

No5%

View Results

How long does it take for you to feel comfortable making fast, high-impact decisions when you’re in a new leadership role? What’s your secret to getting comfortable quickly?

What factors help your team decide that it's time to stop software testing for a release? Choose the top 3.

% of tests executed/test coverage30%

% of requirements covered by testing/code coverage43%

% of total tests passed45%

% of critical tests passed38%

% of critical business flows passed29%

Project deadline is reached21%

Project budget is reached14%

Minimum acceptable defect rate is achieved12%

Go/No-Go meeting11%

Other1%

View Results

Does someone have advice on how they have balanced the risk/reward as it relates to introducing Open-Source Software to organization? My org is dipping its toe into the OSS world and the architecture and risk governance teams are looking to get ahead of these requests by coming up with policies and standards for OSS technology being brought into our environment. To clarify, this is not for software development and CI/CD pipelines, SDLC etc. This is for installing solutions that already exist out there (Zabbix, GreyLog, Prometheus etc.) into the organization's environment. We are looking to provide a balance on the obvious risk with the ability to move fast (like everyone else now).