What is (good) company culture?

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.

The wrong company can seriously damage your health — Andy Williams

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.

Why don’t my Engineers stick to their estimates?

Estimation is a big topic and there are many posts to write on it, but first let’s address one confusion about Software Engineering estimates:

Estimates are not delivery commitments

Maybe that sounds daft or maybe it’s obvious but far too many companies that I talk to are asking their team to estimate in hours, make a deadline at the sum of those hours and then hold the team to that deadline. Guess what – these deadlines get missed. Pretty much always.

noun: estimation; plural noun: estimations

1.
a rough calculation of the value, number, quantity, or extent of something.

Planning

Expectations of delivery date come from a plan, not from an estimate. Plans take in to account availability, team makeup, blockers and dependencies. Estimates do not. Creating a realistic plan can be an art form but it is essential to convert estimates to a timeline that the team and company can believe in. If this process is collaborative or otherwise achieves team buy-in then you have something that people can commit to delivering.

And if your team has committed to a realistic deadline then you have a much better chance that the company can rely on it’s delivery date.


In a future post we will discuss how to get a good estimate quickly and how abstractions like Story Points can lead to better plans.

Dealing with legacy code

At a recent CTO meetup in Edinburgh’s CodeBase we covered the topic of legacy code. Given that this is a common topic and that we had some of Edinburgh’s brightest CTOs weigh in on the topic I thought it would be good to summarise the main discussion points.

What is legacy code?

We started with a discussion about how you would define legacy code. It’s become something of a buzzword alongside technical debt – but how do you recognise it?

  • Hard to maintain – no one knows how it was put together and are afraid of making changes. It becomes that curiosity that gets left because it works well enough and making changes seems too risky.
  • It could have been done better – as technologies evolve and our teams continue learning it will often be the case that we look at an area of our systems and realise it could have been done better. This does not mean it was done poorly the first time – just that it was a while ago and we want to always be moving forward.
  • No longer matches requirements – Requirements change over time and, from a users point of view, so does the software. That of course does not always keen that we’re keeping everything up to date and those trusty core services can quickly become legacy.
  • Too hard to change – possibly the people in a team change, maybe the frameworks used stopped being developed. Whatever the reason if it is not well enough documented or tested things do become hard to change. As [Robert Martin] defines it any code without tests is immediately legacy code!

Technical debt – is it the same?

Technical debt is another term that you hear a lot in the software industry these days. It’s quite possible that people outside of Software Engineering have started to consider it their number one reason why a team cannot go faster. But is it the same as Legacy Code?

No. Technical Debt is the term for those things we know that should be improved but either do not have time to resolve or have decided that there are higher priorities (probably from elsewhere in the business). If technical debt is not addressed then it will probably lead to code becoming legacy sooner than otherwise. Capturing technical debt and prioritising the resolution of the items should help to keep your code in better order.

A common cause of technical debt will be due to a prioritisation on releasing quickly or at a given date where the amount of work required to complete properly would not ideally have been fitted into that time constraint. This typically leads to short cuts or a lack of knowledge share which can obviously make software more fragile than if that could be avoided. As mentioned above capturing these items as they occur and coming back to them later should help avoid stepping on the slippery slope to legacy code.

But when can we do the work required to resolve technical debt? Well we agreed that in an ideal world it is scheduled in immediately – allowing the team to learn from their choices and then work to improve the code before it leaves the collective consciousness (perhaps adapting velocity or other delivery metrics to accomodate). If time really is a pressure factor and releases have to be delivered then this may not be possible. In that situation ensure that your team have the space to reflect on the project and make improvements before the next project truly gets underway and we start again.

Complexity increases over time

At this point the group reflected that it may not be due to any fault of the team (current or past) that led to the legacy code or technical debt. Software increases in complexity over time, that is just the truth of it. What we need to be mindful of is to ensure that rising complexity of the product does not lead to increased complexity of the code itself. Doubling the number of features or the complexity of a single feature should certainly not mean that methods become twice as long – probably not even longer files. Always encourage your engineers to be maintaining a manageable source code, breaking out new files and new modules where complexity grows. And for top marks follow Test Driven Development which will help enforce clean code and a “write the minimum required code” attitude which helps to avoid scope creep and unnecessary complexity.

[At this point we discussed MVP and Prototyping which will be the topic of another post]

Make it maintainable

It was agreed around the room that the appropriate strategy for dealing with legacy code is NOT to replace it but to make it more maintainable (that’s not to say that a replacement strategy may not be right at certain points in time). To turn your legacy code into manageable, workable code the approach is to make it more maintainable – but how?

  • Add (unit) tests – Before you can make any changes to legacy code with confidence you need to surround it with tests. The most effective tests are closest to the code – so aim for unit tests if you can. As the older code in your platform it is often touched mostly for bug fixing, if this is true for you then try enforcing “test first” bug fixing (or even TDD). That way you will gain test coverage over time.
  • A regression suite – Do you have confidence that the UI will continue to work after changes to legacy code? Often functional tests are the first approach to verifying correctness but it can be more helpful to think of this as a second line of defence. If your unit tests pass (fast feedback for development) then a functional test suite can prove a level of confidence that no regressions are being introduced by these changes.
  • Identify problem areas – Once you have an approach for adding tests and growing confidence in your ability to change legacy code it’s important to direct your efforts rather than attempting sweeping changes across the whole platform. With help from support desk numbers or usage statistics try to identify areas of your product where there are a high number of bugs, issue reports or where usage is very high and you would like more ability to add features with confidence. Start work in these areas and you will see fast returns for your efforts – and the ability to make incremental improvement.
  • Small iteration – As above try to identify the smallest change in the areas you have identified and make the appropriate tests, enhancement and roll it out. This will provide incremental improvements to your codebase and to your users. As long as you can always be making your legacy code better and more maintainable then you’re avoiding the same thing happening again.
  • Try virtual machines – If you are struggling to seperate the concerns of your application and finding new areas of functionality are proving unstable by proximity to your legacy code you could consider using virtual machines or containers. Moving the legacy codebase to a sandboxed environment ensures that the boundaries are set and maintained and that limitations of your technical choices do not affect new code. With proper separation the impact of legacy parts of the system should be minimised and will help with any migration plan.

 

 

Learn from it

The main take-away from our discussion on legacy code, other than the need to deal with it, is to learn from it. Legacy code is often a fact of fast development, prototypes accidentally being released to production, and business factors causing engineering teams to not have the time to deal with their technical debt. The biggest action you and your team can take in these situations is to learn what could have done to avoid the situation and to put in place methods that will help to keep the correct balance going forward.

How can we ensure fair salaries when growing?

As any company, especially a young one, grows it will have times when budgets are tight and times when they are not, people will likely be recruited in cycles and you will probably want to hire people from a great many different backgrounds. With that in mind how can you strive for fair salaries for everyone in the business?

This breaks down into a few different areas – I will try to cover:

  1. Paying everyone the best you can
  2. Don’t let the savvy negotiator get paid higher than anyone else
  3. Keep salaries fair over time

Paying the best you can

At the beginning you may not have much money and early staffing may be impossible at market rates. Or you may be in a situation where budgets are tight and it’s not possible to pay as well as you would like. Either way be open about it – discuss the reasons with your team and with recruits when explaining how you worked out the offer.

There has been criticism recently about offering non-cash benefits in lieu of salary – and maybe the point is valid. If you are clear about what you can, and can’t, pay and communicate it clearly I don’t see the problem. If you intend to up salaries say so and if you don’t then say that – it’s all part of recruiting staff that fit the culture you are creating.

Don’t flex your budget for good negotiators

Not everyone likes to negotiate on salary – some like to be valued rather than drive a deal. Others may just not be good at negotiating, and after all that’s not why you’re hiring them (maybe this would help with the gender pay gap?).

The underlying principle here is that everyone should be paid fairly – based on the value they bring to the company. To achieve this it’s important to use an interview to gauge the applicant’s relevant skills and experience to determine where in your pay scale they will fit. It may not always be possible to get this right but being able to explain your working will be valuable.

It’s common when explaining this method for an enquiring mind to comment: “Aha! But that means you should sometimes offer a salary above a candidate’s expectations!” That’s absolutely true. Sometimes an individual has undervalued themselves or perhaps they have only worked at companies that have lower salaries – whatever the reason it’s a pleasure to rectify 🙂

Review salaries regularly and fairly

Everyone knows that salaries need to be reviewed on a regular basis to reflect new skills, additional responsibilities, inflation and perhaps company success. However this is traditionally tied to annual reviews which pose the following challenges:

  • Staff may be less candid about negative comments if they think it could affect their remuneration.
  • Depending on the time of year or funding cycle some staff may get lucky where others could be reviewed at a less profitable time.

Therefore I prefer to review all salaries at the same time either annually or more often. By reviewing all salaries at once you are sure that the funding landscape affects everyone equally and no one is left behind. The flip side of disconnecting from the personal review process is that it may be harder to reflect individual progress but this can be avoided with ongoing objectives and learning which seems like a positive approach anyhow.

Always be fair

Hopefully these are some useful thoughts about keeping pay fair whilst not sinking the company. If you have any other thoughts on this please comment below.

How can we be agile but still have a plan?

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?

How can I improve employee retention?

Engineers are in high demand – it’s no surprise given that software is running more and more of the world every day. With competition for quality engineers being at an all time high it may seem inevitable that you will lose members of your team to better opportunities. To an extent this may be true but it does not have to be a regular occurrence!

Don’t stop people moving on

Let me start by saying that staff moving to new opportunities is not a bad thing. Everyone should be able to work on what inspires them and provides new challenges to keep them in their toes. Having staff that don’t feel engaged or do not share an enthusiasm for what you do will not be best for your team or your company. Sometimes individuals will see / find / be offered opportunities that better suit them elsewhere and when that happens it seems fair to help them make the move. That said there are many things you can do to provide good reasons that people should want to stay at your company.

It’s not about contracts, restrictions or notice periods – it’s about providing your team with the best possible environment for what you are all about. If someone wants to work in search engines it’s going to be tough to be a better place for them than Google – unless geography is important. If you want to build a business networking platform you would need to understand why someone would want to work for you and not for LinkedIn. The key here is to strive to be the best in your particular field. Don’t settle for “people who were turned down at FaceBook” – they will probably be very bright to have got through even part of the recruitment process, but why would they not choose to work for you as their first choice?

The right environment

Consider what you are offering. Are you focusing on the office environment, or the challenges that you are offering to be solved – or is it all about the ability for every member of the team to be innovating in their daily work? If you know what your particular angle is then you will be better placed to engage, recruit and retain staff in all departments.

Make sure you spend time thinking about how much responsibility you can truly offer each new member of the team. Are your key roles all taken or are you expecting to share out many responsibilities as you grow? If you are structured to have 1 large team this may be challenging – you may look instead at many small teams where each member of the team can be responsible for a certain task or role but for a more focused area of your product (i.e. That area which their team is responsible for).

The future – for everyone

Another important aspect of your company’s appeal should probably be training – how can everyone be learning all the time? What opportunities for progression are you providing for everyone including your top level staff? Remember if you want to recruit the smartest engineers you will need to make sure there is always something for them to learn. I don’t mean to say that you need to have a curriculum laid out – many will excel if you simply provide the freedom to provide their own leaning opportunities – but don’t let this look like a lack of consideration for their future! Providing a general path or outlining particular areas of training you know are important would be a great start.

Lastly I would recommend considering how members of your staff can be involved in shaping your product or how it’s developed. If you have gathered a group who are excited about the product you are building then it should go without saying that they may have a desire to shape it’s future! Do you have a product team who can consult with engineers or testers? Or are you set up with cross functional teams? If so great, but don’t forget to delegate responsibility for product areas to the team completely so they can truly own that area of it’s development! If you’re worried about consistency then make sure each of your designers collaborate on this in a similar way to how your developers must communicate outside their team to discuss technology stacks and deployment etc.

Spread the message

Remember that answering these questions is just the beginning. You need to live all these aspects and continue to encourage your team to make use of the opportunities available.

Advertise what is important to you and for your team, hire based on it and stick to it at all times. You will find that your employee retention increases significantly if you can remember and reinforce why you all come to work each morning.