In this article, I discuss a proposal to build a success-primed team to modernize a portfolio of applications. We will take into account our points for alignment from our previous blog post. It’s important to remember this might not be a team that will be long running or one that will become a key part of the enterprise culture. As we discussed in the previous article, there will be a set budget and timeframe to get the work done. What is being proposed in this article is building a team to get results under these constraints.
What is the goal of the project?
Before getting into team structure, you’ll need to answer three questions:
What is the desired outcome?
Who is The Client?
Who will be The Sponsor?
1. What is the desired outcome?
Just as the business case is important for project approval, the value of the modernization project (ie: why applications need to move to the proposed future state) needs to be communicated in a public way throughout project execution.
I once joined a team doing a fact-finding mission about container technology. We had done a number of meetings and were working on a proof of concept. But something was not sitting right in terms of our direction. So, at the start of a session, I opened a presentation with a single slide that asked “What do we want to achieve? Why do we want to achieve it?”
The room got very awkward and quiet. The executive who was driving the project had been sitting at the end of the table listening in. They suddenly got up and left. In the very awkward silence that followed, someone finally spoke up and said, “We don’t know.” I'm sure there was some high-level objective driving this work, but not communicating this with the team was a mistake. We needed that information to focus our efforts.
The definition of what needs to be done and why it's being done should be published in a place that all team members can access. When there is confusion or misalignment, this will act as the ‘north star’ to guide the team.
2. Who is The Client?
After a business case has been approved, generally the business unit that owns the application(s) becomes The Client. The most valuable role for The Client during the modernization project is to validate that the right thing is being built. Specific people within the business unit need to be selected to provide this feedback, and they need to be able to speak to concerns of the business unit’s leadership.
Even if it's a cost-saving modernization (such as upgrading or replacing middleware), there needs to be validation that the changes don’t affect the functionality the application currently provides.
However, sometimes feedback can feel a bit like playing a game of telephone, specifically if the application is used by clients external to the enterprise. The product team selected to do the work might not have direct access to these external clients. There could be many reasons for this, most of which stem from enterprise silos and the squads that form around them. This is an unfortunate situation that is sometimes unavoidable. This brings us to the next important role that underpins a solid product team.
3. Who will be The Sponsor?
If the project becomes blocked or the team is unable to get access to what they need to be successful, a Sponsor needs to be called upon to assist.
It’s tempting to select the person who made the business case for this role. But, as discussed, legacy enterprises can be interesting places. The person that did the business case might have just been the resource available at the time. You need specific things from The Sponsor for a project like this to work:
They should care about the value provided by the modernization
They must understand how the efforts of the product team connect to this value
They should be able to affect change in the enterprise (ideally across silos)
This person will most likely be at the executive level or one degree of separation from that level (and they have the ear of influential executives). This is a critical role should the team meet some of the challenges systemic to enterprise environments.
Team structure
For execution that produces value to occur, the team must be able to easily achieve agreements while balancing the right amount of requisite enterprise knowledge and innovation.
An example of an enterprise team that achieved great things was the Lockheed Martin team that built the SR-71 Blackbird in 1966 (codename Skunk Works).
The lead of this team, Clarence “Kelly” Johnson, wrote a list of rules around how a project should be organized and operated. Once you get past Johnson’s outdated use of pronouns and some of the nuance around the industrial military complex, you will see that some of the rules he made for a team to execute in a highly political environment still stand up to scrutiny.
There needs to be one boss
Johnson said there should be one project manager (who I will call a Project Lead) who should have complete control of the project. Now as we discussed, there are a lot of factors in an enterprise that an individual might not be able to control. This is where The Sponsor comes in.
The Project Lead should be:
Technical
Emotionally mature enough to have difficult conversations in a professional way
Have production experience in the enterprise
Have a direct line of communication to The Sponsor and, if possible, The Client
With these skills and competences, this person should do the following:
Work on, or even own, the architecture of the application
Provide descriptions of work and the success criteria for its completion
Review pull requests on the code base, providing feedback
Meet with clients to collect feedback on the app
Escalate issues to The Sponsor
In terms of discussing the scope of the project or any potential issues in the delivery, the Project Lead should be the one interacting with The Sponsor and The Client. This might fly in the face of many enterprises that wish to have an open culture, but remember that we are trying to execute in a tight time frame. The openness should exist for the team to bring up concern to the Project Lead, and for the Project Lead to report back to the team on what was done about their concerns. Let’s talk more about team size.
Keep the team small
Johnson talks about building “good” small teams. The number of people on the team is critical. Even if it is a big task, the team should be small. This is echoed in the two-pizza-team rule at Amazon.
Fewer people means fewer chances for communication issues, including the risk of overcommunication. Excessive meetings are the death of productivity. But in many enterprises, software cycles are held hostage by endless meetings and sync-ups that never result in a consensus on anything.
Avoid unnecessary changes to the team
Johnson said, “The number of people having any connection with the project must be restricted in an almost vicious manner.”
There is an idea in some enterprises that team members should be rotated in and out to promote knowledge sharing. Although there is value in this, it must be done very carefully with a keen eye on project deliverables.
It takes some time for a good small team to gel and find its groove. Adding new people is a reset and potentially a disaster if the wrong personality is added to the mix.
Once a team has been selected, they should be given time to learn to work together. Once this is achieved, they need to be left alone to deliver. Switching team members should only be done once functionality has been delivered, and with the sign-off of the Project Lead and The Sponsor.
The following diagram depicts the key roles described to date.
The Project Lead and The Sponsor still need to build a productive team to get the outcomes valued by The Client.
Good people to have on an enterprise software team
The ideal team should be value-focused, with the right blend of enterprise experience and industriousness. The requirement for enterprise experience brings us to the next role the team needs.
The Wise Sage
The Project Lead should recruit someone onto the team who has been around the enterprise a long time and who has deep knowledge of how to get code into production in that enterprise environment. Likely candidates should have some of the following competences:
They have put multiple applications into production in that enterprise
They are open to discussing ideas
They have a good relationship with the Project Lead
They have good relationships with critical silos (the database team, infrastructure team, networking team, etc.)
Now, let’s discuss the profile of the product team.
Story Burners who move the needle
Coming back to our original caveat, this work has a set budget and timeframe to get results. There needs to be a team of developers who will agree to join the project and just execute stories for the duration of the project (and let the team know if they become blocked). These are people who are not desperate to stop being a developer, not all-consumed with climbing the corporate ladder and not looking to build their resume so they can leave the enterprise.
The Project Lead should be involved in selecting these resources because the Project Lead will be reviewing and critiquing their work. One of the most difficult situations for a Project Lead is when they are assigned people who they are not comfortable providing technical guidance to. This does not lead to a good team dynamic.
Finally, it’s important that these team members can accept feedback and both understand and accept the value the project is going to provide.
The majority of the team needs to be Story Burners.
People pitfalls to avoid
Let’s look at some personality types you might want to avoid.
Science experiments can cost you time
Some developers just don’t want to be in the enterprise. Perhaps they would rather work for a public cloud provider like Google, Amazon or Microsoft. For these people, adding certain buzzwords to their resume is what they want to get out of the enterprise.
Other developers just like to code with new software, but are not interested in the grind of getting to production or working with something that is more legacy. In short, they just want to play. These types of developers tend to push for “Science Projects.” Basically, these are opportunities for team members to play with whatever tech they are interested in and not be hindered by grinding to provide the promised value.
It’s true that new tech can sometimes be a game changer in a project. But, as I will discuss in detail in a later article, the right choices for an application in an enterprise environment might not always be the right choices from a pure engineering point of view. Exploring new ideas should be something initiated by the Project Lead with input from the Wise Sage.
Political players aren’t always execution-minded
Sometimes your team is assigned political people who, while they may be able to navigate silos, are mainly concerned with climbing the ladder. They may not care about the end user or even if the application ever gets to production. Someone like this might try to push the project in a different direction for their own gain — to put them into a room with the right people to move up the ladder.
Because enterprises usually have an excess of middle management, sometimes someone senior will throw people like this into a project, and there is no way to push back. In this case, the Project Lead needs to be empowered to escalate to The Sponsor if someone is derailing outcomes for political gains.
Setting expectations with management
Thus far, we have established the following basis for building an ideal modernization team:
Agreed value the modernization will provide
A Client who will provide feedback
A Sponsor who can unblock the project and understand the importance of its value
A Project Lead with deep technical skills and experience in the enterprise
A Wise Sage with tons of experience and relationships in the enterprise
Developers who are ready to close the stories assigned to them and can take feedback from the Project Lead
In my next article, I’ll discuss how to decide on your strategy for modernization.
Modernization series
About the author
Luke Shannon has 20+ years of experience of getting software running in enterprise environments. He started his IT career creating virtual agents for companies such as Ford Motor Company and Coca-Cola. He has also worked in a variety of software environments - particularly financial enterprises - and has experience that ranges from creating ETL jobs for custom reports with Jaspersoft to advancing PCF and Spring Framework adoption in Pivotal. In 2018, Shannon co-founded Phlyt, a cloud-native software consulting company with the goal of helping enterprises better use cloud platforms. In 2021, Shannon and team Phlyt joined Red Hat.
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit