Tips for Architecture Management/How to Work With President Business
Life as an architect is hard. Here are some tips to help you manage your software architecture whilst also keeping the business happy.
Join the DZone community and get the full member experience.Join For Free
Some days I think that life as a software architect runs like the story from the LEGO Movie:
"We have to do the right thing,
save the world,
free the master-builders,
prevent the destruction of everything,
beat the bad guy,
but also -- fall in love with the business,
help them to understand why they feel the way they do,
guide them to enlightenment,
so we can all live in peace and prosperity together."
There are so many obstacles to success and a big part of managing your software architecture is getting the business folks on board, getting them to understand what you are saying, why you are saying it, and convincing them that the changes you are proposing are worth the investment. But why? Why is it so difficult to convince them, and why are we not all on the same page to begin with?
I will present one idea about why businesses and architects see the world so differently and, then, I'll give some tips for how to manage your architecture successfully, even given the challenges. I'll show you how to be a master builder and save the world.
Intrinsic and Extrinsic Motivation
As software architects, those of us who aren't lost in our ivory towers, really LOVE our software. It's our baby. We want to look after it, nurture it, tend and care for it, and help it to grow and get better. We understand how it works, what it's good at, and what it's bad at. We long to remove all the cruft to simplify and polish it. We are motivated from within to do the RIGHT THING with our software. Solving difficult technical challenges and building beautiful software is what gets us out of bed in the morning. We are "intrinsically" motivated. We don't need any external impetus to do what we do; we do what we do because we love it.
But, now, let's look at other people in our organizations. Not everyone is motivated from within. Not everyone sees the bigger picture. Some people are motivated by very different things, such as simpler, more superficial things. Some people just want to hit their targets, make the revenue figures, or meet some metric or other. As our careers progress and we rise up within our organization, we tend to find more and more people who are motivated this way. I'm sure they are lovely people, and I don't want to tar them with the "pointy-haired boss" brush but, well, there certainly are some parallels with the famous Dilbert cartoons. Some people, higher up in the organization are not there because they care about the product, or the customer, or this thing or that thing. What gets them going is hitting the mark, pleasing their boss, getting a bonus, or whatever else. These people are motivated by external effects. They are "extrinsically" motivated. If you took away the external factors motivating them, they wouldn't know what to do.
Of course, I'm simplifying a situation that is much more complex in reality. Not everyone is one thing or the other. Not all bosses are extrinsically motivated and not all engineers are intrinsically motivated, but there are some trends there. Perhaps it makes perfect sense for those above to be extrinsically motivated, as they ultimately need to please their shareholders and that means making the numbers.
Some traits and consequences of these types of motivation I've summarized in the table below. (If you'd like to read more about this topic please see the references below).
Okay, well, "So what?". Well, let's consider a hypothetical example -- imagine we have a car and it's either driven by an extrinsically motivated person or an intrinsically motivated person. Let's imagine that our business tells us "drive the car a long way". More miles means more success. The extrinsically motivated person will be engaged by what the business says and will drive the car as far as they can, even until the wheels fall off and the car breaks down. The intrinsically motivated person loves the car, they tend the car, service the car, paint it a nice color, and keep it clean. Perhaps they don't drive it as far as the extrinsically motivated person... in the first year... but they are able to keep driving the car forever. So, in the long term, the business wins with the intrinsically motivated driver.
It's a bit the same with architecture management. As technical wizards, we can look at our software and see it for the messy, inefficient, disorganized thing that it is, and we are driven to fix it. The business bosses don't see that and are more motivated by things such as revenue and the number of production incidents. They are unlikely to support our requests to fix the software unless it very clearly supports their own motivations. Maybe we don't like that but that's just how it is.
What Can We Do About It?
Clearly, if we are to take care of our beloved software we will need to either find a way to win over our bosses or find a way to make the software changes without otherwise preventing the bosses from achieving their own goals. Here are some approaches we can use:
1. Sell the Architecture Change in Terms of Short-Term Improvements
It's just about possible to sell architectural changes in terms of short-term improvements. Perhaps you can make changes to prevent the recurrence of a recent production issue, or to address some well-known technical debt. You'll have to frame it so that the bosses can see that by investing a little in architecture they can achieve their own goals. For example, they may be driven to improve up-time metrics and you can help with that.
Somehow you, as architects, will need to have a background plan to be able to stitch all of these small steps into a longer-term architectural transformation, so you'll need to be canny and steer things as needed. As the figure below shows, sometimes architectural changes require a lot of effort before the benefit starts to be seen. You'll need to be particularly careful to manage expectations and sell the vision in these cases.
2. Build Trust
It's always a good idea to strive to build trust in your organization. If your boss trusts your judgment and skills, they might give you the benefit of the doubt, or otherwise some leeway to go ahead and make the changes you want, even if the benefits are not obvious to them, at their level. They will be more open to listening to your opinions and might open up about what they see as important. It's not a battle of you against them of course, we do want to win the business round and look for win-win situations as much as possible.
3. Get Ownership of the Asset
In the best case, the case where you obtain the full trust from your superiors, your boss would leave managing the software asset to you and the other architects and you could then make your case for how much time and money you need to be successful. You'll still need to highlight any successes you achieve, of course, and sometimes it helps to form an architecture management team to manage the changes and communicate the plans up to the higher levels. You'll still have challenges due to silos within the company, perhaps, or cultural issues but you'll also have far more freedom to create a coherent vision for your software and engage the engineering teams to move that forward.
4. Find a Way to Get Innovation Time or Have an Innovation Budget
Some Agile approaches, such as Scaled Agile, attempt to build innovation time into their regular SDLC. This can be a very positive thing and gives engineers the time to blow off steam, do something radical, or fix some technical debt that's been bugging them. It's great for creativity and building morale amongst the engineers. If your firm is prepared to invest in such approaches, your role as an architect can be to help align the innovation activities and technical fixes so that, at least, they are all pulling in the same direction. Ideally, they'll all be helping to transform the software and its architecture into something you're aiming for.
If your firm doesn't want to invest in regular innovation efforts, perhaps you can spend some of your time trying to convince them that this would be a good thing to start doing. All the best software companies do it already, of course ;) .
5. Engage the Intrinsically Motivated People
This ties in with the previous point. Software engineers love software so find a way to give them the freedom to do things they love. You can create a virtual team of (probably senior-) engineers and encourage them to discuss how the software asset can be improved. You can sell your vision of the future to them and get them excited. You can ask them how they might see the software in the future and discuss what would need to be done to get there. If you can just agree on the direction and all get fired up about the vision, things do tend to have a habit of just getting done. People mention things to other people, ideas change, folks find a quiet minute in their coffee break to just do this one little thing, and if you keep poking and prodding, you can build up quite a bit of momentum with this.
If your organizational structure supports it, another thing you can do is give teams local autonomy over some of the software. You can empower them by giving them the authority to manage the architecture over the systems they are most familiar with. Low-level changes they can be responsible for and only the higher-level changes will need your involvement. This builds trust and autonomy and again helps people to get excited about what they're doing and make things better. Some degree of transparency is needed, however, to ensure that teams' efforts again play into the bigger picture, longer-term plan.
6. Work With the Product
Product managers can often be supportive of architectural changes, so it's worth spending some time with them, talking through the various options. It might be that once the product is reshaped architecturally it opens up new possibilities for engaging with your customers or might create new ways existing products can be used together. Sometimes you can reduce the time-to-market, and so on. It's worth investing in the relationship you have with the product managers and trying to find common ground that supports the needs of both these functional areas. Then they can help you get the time and resources you need to move your ideas forward. If things go well, you might be able to create a combined roadmap that shows how both architecture and the product will advance together over the coming years.
7. Change Your Organization
This is the biggie, of course! Often, the way your organization is run and structured will stand against you, will block useful dialogue, and will put bureaucratic barriers in your way. There's no doubt, it can be a real pain. Removing those obstacles, or softening them, can be very difficult, and there's no suggestion that it's necessarily an approach you should take.
Nevertheless, here are some pointers in case you do wish to poke your stick in the hornet's nest:
- When the opportunity presents itself, you can try to educate people about intrinsic and extrinsic motivation. You can help people to understand the differences and how they shape the organization. You can gradually build awareness of the issues.
- If your organization uses metrics as a means to motivate people and drive work, you can endeavor to show people that this tends to inspire short-term thinking and the long-term behaviors needed to manage your software successfully may suffer. Metrics might be vital to track progress, but people need to be motivated by the bigger picture. Without that perspective, we tend to use short-term actions to drive the metrics at the expense of the longer-term view, which is what the metrics were intending to support in the first place.
- Find the key movers-and-shakers in your organization and establish relationships with them, and seek to understand their motivations and desires. Build some common ground and start to discuss what your perspective of the company is. Point out which aspects of the company structure are holding things back; maybe there's heavy siloing, maybe short-term thinking is causing some explicit problems. Look for ways in which you can both benefit from some changes.
- Take a look at the geographical aspects of your firm and how that might also have a role in shaping the software that you make. You might find some of the changes you are trying to make are held back simply by the way people interact and the difficulties of remote working (this is called Conway's Law).
It's very hard to successfully change your organization, but it's worth having a go. If you find yourself in a more senior position and have the opportunity to make changes and drive them through the organization, you could take a look at John Kotter's "Leading Change" for a thorough course on how to do that.
So, there you have it, some tips and tricks to help you care about your software and manage it, even though the organization as a whole might be less concerned about the intricacies of that than you are. Perhaps it helps you understand why things are so difficult sometimes. But, just remember...
"You don't have to be the bad guy. You are the most talented, most interesting, and most extraordinary person in the universe. And you are capable of amazing things. Because you are the Special. And so am I. And so is everyone. It's about all of us. Right now, it's about you, and you still can change everything."
"Corner of a LEGO piece - Macro Mondays 'Corner'" by aparlette is licensed under CC BY 2.0.
Opinions expressed by DZone contributors are their own.