Culture is a hot topic these days – if your young company does not have a culture then it’s not a cool startup right? Well let’s just stop right there. A business culture is not optional – it’s not something that you may or may not have – it is there whether you noticed or not. The question is do you know your culture and are you being intentional about reinforcing it every day?
Let’s look at this from another angle for a minute and consider what a culture is not:
- it is not having a games machine, pool table or table tennis league
- it is not dressing down on a Friday or having a casual dress code
- it is not having flexible working hours or a short week
- it is not painting the walls a bright colour or replacing your walls with glass
- it is not providing breakfast, lunch and dinner in the office
- it is also not installing a beer fridge
- most of all it is not writing values or behaviours on the office wall!
Before I get angry comments let me clarify – a company with a good culture may have many of those things – but they don’t define the culture.
With that out of the way, let’s consider what does make up a company’s culture. As with culture outside the office place it can be described as the way that people behave and communicate – it’s the conventions by which any group agrees to collaborate and probably incorporates shared interests of some sort. So you see, culture exists whether or not we intend it to – without careful consideration it will become the sum of the personalities people you have hired.
A Wall Street trading company may have a culture of wealth aggregation, a charity organisation probably focuses on improving the lives of a segment of society. The culture within your company may reflect the work you do or it may not. Your culture may have a social pub-each-evening focus or your office may be 9 to 5 desk workers – neither of which are defined by your industry or product offering. So if it is such a vague concept that seems to be influenced from every angle then how can it be shaped?
They say that culture comes from the top, and most of the time that is true. Company leaders behave in a certain manner – they exhibit values or behaviours that the rest of the company adopt over time. Those in the business first hire everyone that follows and they probably pick people that share their values. If, however, the team is purposeful about it’s culture – sharing an understanding about what drives them or communicating a set of values then the culture will follow. What you (as a company leader especially) must remember is that you need to live these values and exhibit the culture that you wish to see in the company. Otherwise it’s just another example of leadership delusion or an exercise in futility. Be inspired by other’s successful cultures of course, but make it your own.
Remember that great company culture is worth defending – it could be why many of your team come to work each day.
One of my favourite topics is startups – discussions about the benefits of young companies and how innovative workspaces can be a boon to productivity and healthy work life balance. It would be remiss of me, however, to imply that it is always great. There is a lot of hard work involved of course but […]
via The wrong company can seriously damage your health — Andy Williams
Full disclosure that is from my personal blog but I thought it was really relevant so I wanted to post the content here as well.
This comes up a lot – usually because a CEO complains “My engineers say it will be ready when it’s ready – they can’t give me a date” or a Project Manager may be concerned that “With time, functionality or quality you can have only 2 – but we won’t flex on quality or functionality and the board need this feature on time”. Clearly these are valid concerns and there is no magic bullet but this is usually as a result of misunderstanding the agile process or being more familiar with a waterfall process of project defiition.
So how can agility be maintained within the scope of a plan? By realising what it is that the team is actually building! As the agile process is about delivering value quickly rather than specific features we can see that a feature list or requirements document paired with a deadline is missing the point of the process.
The outcome of each iteration within an agile project should be a releasable set of functionality that works towards the desired value. Some times the value can be realised in a single iteration (remember to celebrate even the small successes) but most of the time projects will be much larger and contain much uncertainty. When this is the case how can we promise release dates or promise to deliver certain improvements for a deadline? Estimation.
The process of estimation is important for understanding the scope of work as well as when it could be delivered by. A good estimation meeting will involve members of a team from all areas of specialism (development, testing, design etc) and should have people faimiliar with all the areas of the product that could be effected. Whilst estimation is based on completely abstract concepts (story points or t-shirt sizes) these mean something to the team and can be used to understand likely completion dates. A consistent team that is adept at estimating complexity by digging into the details can be relied upon to deliver, on average, a consistent amount of work in each increment. This is the baseline for a realistic agile based plan. The other key element is to continually be reviewing the upcoming work (backlog) to answer questions or explore potential solutions. Bringing these together will create a reliable and sustainable environment for planning.
But I want to plan further out – not just a couple of sprints… Fair enough, there is a business to run after all, and we need a long term plan as well. Here the key is to realise how many unknowns and how much complexity there is in each project as it goes through the process. If you have an innovative environment then the team will never be solving the same problems twice so this can seem like an impossibility. But let’s come back to the concept of delivering value. The plan is to create a new area of functionality for your product by a certain date. Great. Share the high level requirements, let the team explore the approaches and possible features that could deliver this value. With that in mind they can estimate what a complete solution might involve and give an educated estimate (/guess) of delivery date and start the work to incrementally deliver it all.
Of course the overall benefit of working incrementally toward a hypothetical complete solution is that there will be various releases possible along the way. If the team is good and you have articulated the desired value it’s entirely possible that you could either get something that is delivering this value earlier than expected – or that you learn that the envisaged solution was not actually the best way to deliver the value to your customers.
With these possible benefits and the overall improvement in communication that an agile approach requires how can you long for the days of a step by step project plan that becomes out of date at the first unexpected complication?
One of the questions I get asked most often is how to stay up to date with everything in the fast moving world of software and technology. You know what, it’s not going to be possible to know the ins and outs of the coolest framework in every language. It’s also long past the time when you could know all the various support tools that your team might benefit from using.
Let go of the concept of knowing everything and trust instead that your team, who are working on the actual software development day to day, know the details of the technologies needed to get the job done. Instead focus on a higher level – are there ways the team could be working better together, is communication clear, are people learning a wide range of skills. Where you see opportunity to help improve something then by all means investigate options for the software / tool / platform that might help – but don’t go to your team with solutions, help them to see the opportunity to improve and work with them to get the right solution.
Remember that your team is full of smart individuals at the top of their game (if not then there’s another question to look at) and they have either already seen the problem but not had time to address it, or are going to be much more interested in a solution that they were part of finding rather than one you brought to the table!