Why Contexts Matter

​One of the words you’ll see *a lot* in these posts is ​context​.

Context is probably the most important word when you’re running a team, or you’re an architect, or in general you just want to enact change on your team or your organization.

There’s a lot of advice out there about ‘best practices’, and generally that advice lacks ​context.

​In your business, your team, and even in this moment in time, you exist in a particular set of contexts:

Social Context: What is the social structure of your team? Who gets along with whom? Who has lunch together? Who does everyone tolerate but not really ​talk to​?  Who if they left today would make the biggest hole socially?

Financial Context: Has your business given you a raise in the past year?  Did it track inflation?  Was it a 1-2% raise?  Did your company make its sales goals last quarter? Last year?  When’s the last time you asked about the financial health of the company? Do people even do that in your company? Are there all-hands meetings where the financials are brought up? Do they talk about profit or just revenue?  What’s your run rate?  What does it take to get a book in your company? Any book related to your job? What does it take to get a conference approved? A new piece of software?  Is pay a big secret? Do you know what your coworkers make?​ How long can projects last before they’re considered a failure?

Technical Context: How does your team and business feel about the word ​legacy​? Is your software considered ​legacy ​or ​modern​? How do team members feel about making changes to your system? What did the last big project feel like? Did it succeed? fail? What caused it to fail? What helped it succeed?

Cultural Context (can also be called “Political Context”): Who gets ahead and how? Who is rewarded?  Why was the last person fired? Do you know? Does anyone? What’s the turnover rate, voluntary and involuntary? Does the messenger routinely get shot?  How long does it take you to hire? To fire?  Do you have yearly reviews? How are they conducted?  

​Business Context​: What’s your team’s business model? Your company’s?  How does the code you write get translated into value? Is your team considered a profit center or a cost center? (Do you make the business money or cost the business money with each new thing you build?)  If the former, is your value creation axis centered around saving money or making money? How do new initiatives get approved? Who has the easiest time getting new initiatives approved? Who has the hardest?  Quite simply: Who holds the power in your chain of command? Is it the person who is in charge by title? or is there a shadow chain of command? People who have the influence but not the title? Is your boss or your boss’s boss a key decision maker or do they report to the key decision maker?  Does your CTO sit on your company’s board? If not, who does besides your CEO?

Why do all these questions matter?

They matter because whether we realize it or not, all architectural decisions your team makes has to take all of these contexts into account.  Let’s say for the sake of this discussion that you want to ​modernize​ your .NET application. Maybe move it to .NET Core, maybe containerize it, maybe even split it up into microservices.  All of these questions matter, because they help you decide what you ​can​feasibly do​. If a project that last longer than three months is culturally or fiscally shunned, then you’re going to need to find a way to make a splash in 3 months, something that will help the business respond ​positively​ to the changes you want and need to make.  Technical decisions aren’t simply technical decisions. They’re decisions that are made with all these questions in mind, because change — technological change — is a tactic to fulfill a goal or improve one or more of these contexts. If it’s not made with these contexts in mind, it’s busy work at best, and damaging to your organization and reputation at worst.

And most importantly, if you don’t have the pulse of your organization — if you can’t readily answer these questions, then you’re ignoring the part of the organization that ultimately dictates success and failure: the human part.

Leave a Reply