Let's start with the question:

How does the organization you work for (outside of your team!) impact your everyday's work (as a software engineer)?

I mean:

• what does the organization do to make you / help you become a better engineer?
• what's being done to make your current workplace a better work environment?
• do you feel your org believes that your potential & creativity can make a difference? or are you just to do (as literally as possible) what you're told to?
• do you feel there's someone thinking about developing your potential long-term? in other words - do you feel like you're being invested into?

Not sure about what qualifies & what doesn't? OK, let's try some guiding questions ...

1. what are your interactions with other teams except of these related to day-to-day project work?
2. do you have any kind of influence on who you'll be working with (teams switching, recruitment)?
3. what's the org's approach to experiments - do these officially exist? are they encouraged in any way?
4. what are the ways knowledge is being shared in your work environment (project-specific, industry-specific, domain-specific, generic technical, ANY kind of knowledge)?
5. how is your work (and / or work products) evaluated? based on what factors / metrics / opinions?
6. where does your autonomy end? what's the level of trust your org puts in you?

Done? Good.

Software engineering ... culture?

What was the point in asking these questions? The answers to them are very helpful in assessing org's contribution in shaping the engineering culture of your workplace. Definition-wise:

Software engineering culture (SEC) is defined by values, behaviors, principles & actual practices (technical & non-technical as well) that are being actively promoted, encouraged & applied in everyday work of software engineers in your company (or unit or whatever).

Don't get me wrong -> SEC can't be "designed, packaged & literally executed" solely by the employer as it is being shaped (yes, a continuous process) by whole community (consciously or not), but companies & all levels of management can have a significant impact (especially negative) by promoting or blocking particular behaviours (thus affecting the conditions in the environment).

I have some observations & my conclusions are rather sad - majority of companies that employ programmers either don't understand or underestimate the importance of conscious building the proper software engineering culture.

Frankly speaking, in surprisingly many companies I've had some contact with, developers ...

1. ... were supposed to turn requirements into working code. Period. End of (user) story. In their breaks they should not wander/talk to much, so others are not interrupted & can complete their tasks as well.
2. ... should be happy, because they are paid well (better than in other industries) & that's what should matter. If they are unhappy, well, a raise can be considered if it's justified by sheer performance (efficiency, preferably measured with lines of codes committed / number of bugs fixed).
3. ... should follow the well-trodden path: documented, stable, well-known, standardized (so even a monkey can take over if needed). The more deviation from the norm, the worse.

It's actually very typical that employer doesn't care about differentiating its own development unit from the competition (and then they wonder why people are not "loyal" at all ...) - the only shared values they can come up with are:

• before the deadline
• all "blockers" & "criticals" closed, "highs" with workadound, "medium" & below are ok

So what?

I acknowledge the fact that for many that may be just fine. It's just a work after all. An occupation. Cool.

What I don't like at all is that more & more passionate developers claim that this becomes more of a standard in the industry, even in companies that find themselves ambitious & operate in highly competitive markets - if you give it a thought or two, it looks like an outrageous waste.

For the sake of comparison, let's list some actions implemented by companies that understand the important of SEC (this list is inspired, but not limited to, by recent speech "Building an engineering culture", presented by Marek Kirejczyk at Agile By Example 2016):

• organising & hosting conferences, meetups & other professional events for software developers (open for externals)
• regular internal hackathons as occasions to try things out, learn & innovate
• clear & transparent rules for controlled experiments
• well thought (& carefully prepared) on-boarding aimed to make new-joiners feel special & infuse them with org's core values since the very first moment
• high appreciation of individuals' various activities within professional communities - as conference / meet-up speakers, etc.
• encouraged & promoted contribution to the Open Source products & open sourcing own products
• not only providing various source of information & professional learning, but also arranging knowledge exchange with renown external experts & authorities
• huge attention to recruitment process -> current team members come up with creative, unconventional ways of candidate verification, aimed find really good fits

Clearly, additional effort (... & money) is required to do all of that. Is it justified? Does it change anything in a way that it pays off? Would it matter for you - to work for an employer who implements such actions (if your one doesn't) or get rid of these actions (if that's what your current employer does right now)? Would it make you feel ... more proud? More engaged? Or maybe just to care more? Give you more purpose?

Let's leave it like this for now. I'll let you judge it by yourself without any more comments.

Pic: © Photobank - Fotolia.com