Series of personal essays inspired by blog post Things I have learnt as the software engineering lead of a multinational
On Planning
There is a time for everything, a time to share detailed messages, and a time to share higher level thoughts.
When leading a team there are two very different scenarios you will end up in:
- Where tasks are well-defined with easily measured goals. However most of the time, they would fall under
- Tasks which are unclear, with unknown requirements without a clear plan
Based on both of these two situations, our communication style should change accordingly. To determine the proper way it is all about how you might frame your message.
The Rise of the Unknown
Within an organisation, as you move up the ranks, tasks and projects generally become more and more uncertain - that is a good thing! It means that you are being placed on projects where you are expected to voice an opinion. What is important is to realise that not everyone’s opinion is equal and not to be disappointed when your opinion is ignored - it may very well be ignored for legitimate reasons based on a larger overall picture that is beyond your remit.
Because of this, I would generally advise caution and open communications is more important than simply being “right”. Similarly, in the vein of open communication, the more vague the result or direction is the more we should frame our opinions not as fact; but rather as probing questions to understand or reveal what exactly is the larger strategic plan to seek general guidance on making a more informed opinion. This will help reveal people’s assumptions, which may assist you in challenging them, or have your own preconceived notions challenged. This is particularly important when designing and understanding pieces of work related to enterprise architecture and strategy.
Through this, it is clear that communication is extremely important. Based on this, my belief is to avoid being overlly correct when framing problems. As I work in an engineering/analytics space, many analysts and developers can small BS from a mile away. It pays to be honest and forthright particularly when the correct answer is “I don’t know”. Afterall, many conversations occur simply because people want to hear and share the situation they are in. They is no need to paint a rosier picture than what you know, simply because that would place you into an uncomfortable corner. Having a common understanding and language when dealing with unknown situations will serve to bond the team and at the same time resolve any issues early. At the same time, there are times when explanations fall on deaf ears - this could be due to ignorance, or more commonly, the belief that it doesn’t affect them at that point in time. Whether this is correct or not, there is no need to be offended, simply keep communication open and honest with anyone who is willing to listen.
On Communication
Teams don’t self-organize unless you organize them to do so
My favourite experience with lack of self-organising team, is two small teams with first line leaders (but under the same wider team) worked on delivering a piece of work to the same stakeholder. Now one team had worked with this stakeholder for many months, whilst the for the other team it was their first piece of work. When it came time for the newer team to deliver, they didn’t speak to the incumbent team!
Can you imagine the consequences of this if the stakeholder received different pieces of work from a single wider team which contradicted each other? It wouldn’t matter what quality of work was delivered or the precision of the analysis, any rapport that had been built for the preceding months would have been destroyed simply due to the inability to self-organise and communicate effective with one another.
To enable communication within teams we need to ensure that there is a suitable catalyst. When you co-locate people, it doesn’t guarantee that they will have better communication with each other as oppose to people another state away - it simply lowers the cost of the catalysts - essentially there is no free lunch or automatic way to ensure this happens.
The easiest way to ensure that communication exists is simply to ensure people are on the same project - however that is often not sufficient! Even in the example above, we had work being delivered to the same stakeholder with two different leaders who did not communicate or align themselves to deliver consistently to the stakeholder. This suggests that there requires a level above, with a consistent strategy in order to ensure that teams communicate efficiently. Moreover, suitable patterns for communicating across teams need to be developed, identified and expressed. What makes this difficult is different organisations would prefer different set-ups. There isn’t a clear or obvious pattern that would universally improve communication.
At the same time, ensure that you have vision. The lack of vision is not agile, or data-driven and should never be thought of as a positive aspect. It’s simply a lack of vision. When projects end or lose funding, it is important for the morale of the team to understand what is the end state that needs to be achieved, and have a firm understanding on whether it was a success or failure. Too often projects are marked as success by moving goalposts - I perceive this to be a lack of vision over maliciousness.
On Resourcing
As much as we wish it were the case, management is not the same as a burger chain, factory or sweat shop. Talent is often not interchangeable; just don’t use this analogy or method for resourcing or communicating with the team. Simple example is that there will be people whose specialty may be specific parts of Machine Learning (e.g. natural language processing), if they were to work outside their specialty, they may struggle, similarly expecting a junior developer to jump in and help might be disastrous.
When selecting candidates, make sure that you do test their actual skill. If you cannot test their skill, then it may mean that you are not competent enough. Furthermore ensure when selecting technical leadership roles that there are two to hold each other accountable. It is easy for a solo person to dictate their own agenda without being held responsible for their actions. This can lead to problematic decisions in the technical sphere which are determined by the flavour of the month rather than based on solid principles.
Similarly, get more resources for the right reasons. Being overworked is not a right reason, and may be signalling some systemic problem in arrangements. Hiring should be done to capitalise on opportunities, not current battles. Based on this, it is fine to lose battles - don’t feel the need to win battles at all costs, as the cost to personel might be more damaging that you initially anticipated.
When leading teams and others it is important to train and ingrain the importance of open communication and promote personal initiative. This means demonstrating that this is a vital need; not merely a nice to have. These are birds that mostly don’t fly out of the cage just because you open the door. You must find a way to show them that the cage is burning.
On Personal Growth
There is more material than you can ever imagine. Don’t despair - keep reading. This is particularly important as you may grow towards leading without doing. However, be sure to keep doing, to ensure what your leading is still relevant and correct. At the same time continually have a learning mindset - ask questions, not only to yourself but to others. This is for both your benefit and their benefit (n.b. “do you understand?” is not a valid question!). On the same token, stay sceptical of new ideas and feel free to challenge and disagree with them when they arise.
Don’t be afraid to cancel meetings, at the same time do spend time to coach and teach people who have strong potential. Use your time wisely rather than depend on useless meetings. Similarly don’t create dependencies on your work or decisions. Ensure that others are well equipped to make decisions with or without you - and that you are comfortable with them doing so.
On Projects and Stakeholders
One of the key lessons I learnt is to tailor your message. In an organisation that is not inherently analytical - do not consider model outputs to be “done”! Having a strategy or a plan will go as far as the level that can be understood. Often in large organisation this means, not much. This might mean you will need to take others on an analytics journey to ensure they are more comfortable to use analytics assets which are created.
Ending
Its been useful to reflect on my last few months, and the essay written above.