The mindset influences the success of a company - and vice versa.
A company’s mindset is defined by how people work together, communicate, and view their work/product. An attractive attitude for me would be that people follow the Agile Manifesto daily, have an honest, open, and same-level type of communication, and are proud of their product, work, and company.
” Please describe your ideal workplace” is a typical question in a job interview. Even though it seems like a standard question to check if the candidate would be a match, the actual intent of this question is to see if the candidate has a clear opinion on his working environment and can articulate that. So, whenever I’m hiring for a dev/DevOps/it position, this question will eventually pop up at one point or another during the process.
As an outside person, you might think, “Why would a developer need to reflect on his workplace? After all, a developer will spend most his time in from of monitor, coding stuff…”
That might be - and probably is - true. Still, when a person reflects on his ideal workplace and can name a couple of essential criteria, it shows that this person brings a certain mindset, that he cares about the company and the culture where he’s going to spend most of his daytime.
The mindset
Hire the mindset and train the skills is a commonly used phrase, describing that if people only bring the right attitude to the job, you can teach them all the rest, and your company will prosper and earn billions of dollars - or so people think.
I will focus on hiring and teambuilding later in this blog, so let’s look at this mindset-thing: what is it, what’s it suitable for, and why is the company’s mindset crucial to me?
Let’s take a look at a definition of” mindset”:
A mindset is the attitude [of a person] towards life in general.
For a company, we can change to this definition:
A mindset is a company’s attitude towards being successful in general.
This attitude covers the three areas:
- How do people work in that company?
- How do people in the company interact with each other?
- How do people in the company look at the product?
How do people work in that company?
This bullet point relates to the actual process of daily work. The most important virtue in my daily work is the Agile Manifesto (a.k.a. common sense, as I like to point out):
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The Manifesto explicitly mentions the things on the right because they are essential and have every right to exist in a company or a team. It’s just that the stuff on the left should be valued higher when it comes to working.
- Individuals and interactions over processes and tools - let’s talk about a new requirement before hacking it into JIRA and giving everyone a headache because no one understands it
- Working software over comprehensive documentation - when it comes down to a deadline, let’s focus on delivering a working artifact rather than a fully documented but unfinished piece of software
- Customer collaboration over contract negotiation - have the customer involved deeply in the development process and not just deliver status emails or project plans because that’s the only thing defined in the contract
- Responding to change over following a plan - while it’s essential to have a plan on what you want to do, nothing is as persistent as change. So, make sure you’re not sticking to a plan just for its sake, but when circumstances change, e.g., the market you were currently focussing on became irrelevant for your business, be ready to change the plan!
The Agile Manifesto gives a guideline for how developers, products, sales, support, and all the other units in a company should work together. It doesn’t define a process, like Scrum, that companies have a hard time adapting, usually creating a hybridized monster like Scrum-ban without even realizing what Scrum and Kanban are and why they should co-exist instead of being mixed up.
A process should always serve a purpose - solving a specific problem. Don’t ever try to establish the only method for every situation. A genuinely agile company would be able to adapt its way of working to the issues at hand. You won’t be able to solve tomorrow’s problems with the same process you used to become successful yesterday. The fundamental idea behind the Agile Manifesto was to establish a way of solving problems iteratively: Identify a problem. Think of a solution. Implement the solution. Deploy the solution. Test the solution. Evaluate the solution. Learn. Neither does it say: You are allowed to think of a solution for only 90mins per week, nor does it say, if your PO didn’t write a ticket, then it’s not a problem.
So, I value companies that have adopted the four virtues of the Agile Manifesto in their daily work - even if they don’t name it that.
How do people in the company interact with each other
If I have learned one thing in my career: treat people as the grown-up they are. Including:
- giving trust - something you’d give as well as receive as credit and that pays out over time
- a humble and respectful communication - on eye level, always focusing on the actual subject without getting personal
- fast, open and honest feedback - in both directions up/down, in a matter of fact sense
I trust people that they will find the right solutions, make the best decisions, do the proper implementations or hold each other responsible for the company’s success. On the other hand, I would expect trust from these people that I would also only do what’s suitable for the company. This trust is the most basic requirement for working together - there is no team, no result, and no success without trust.
Many people are better developers or managers than I am, or they know much more about the business. So, it’s only reasonable that I talk to my co-workers on eye-level since I will always be able to learn from them as much as possible. And as the term “co-worker” implies: we are working together on a problem and will only solve it together. We discuss without emotions with a clear focus on the subject at hand - how many innovative and helpful business ideas have been yelled down in a meeting because someone couldn’t discuss things professionally?
Giving feedback is still not a very common thing to do in German society. People - and I explicitly include me here - are still thinking that giving negative feedback is rude, and giving positive feedback is at best patronizing. At worst, it weakens your position because it’s like admitting: “You’re better than me.” On the other hand, when we receive honest and open feedback, we feel like someone dumped us, feeling like we’re doing a bad job or that we are a terrible person, making us feel inadequate or fear losing our job. But giving and receiving feedback is essential - evolution and personal development depend on the feedback we’re receiving from our environment. It’s a question of how to provide feedback, if it’s a safe surrounding, if the input is validated and if it’s sincere.
How do people in the company look at the product
Are the employees proud of the product or not? Are they coming to work just for the money, or do they jump out of their beds every morning eager to run to the office and start working? If people don’t love their job but rather see it as a duty or worse as some punishment, it can cause a poisonous mindset inside the company. Those people might start talking behind the back, spreading rumors, and creating an atmosphere where their co-workers feel uncomfortable. It may sound quite arrogant or unrealistic to expect that people always come to work when millions of people are happy to have a job or need to take on multiple jobs to feed their families. Fair enough, and Kudos to those people! On the other hand, we are talking about a very particular market. We are blessed to get paid for something we’d do as software developers because we love to code. And if people don’t want to code for their current company or that specific product, it’s ok as long as they go and look for something else. There is no need to get engaged in company politics or talk behind people’s backs. I would always expect a software developer to deliberately choose this profession and workplace and come to work with a smile because she will do what she loves the most for the next 8 hours.
So, suppose I see that a company tries to follow the Agile Manifesto. In that case, however they call it, people communicate in an open, trustful, and honest manner and love their work - well, that’s what I call a great company mindset.