My experience comes In the context of software engineering, but I believe this summary would apply to leaders in any industry sector.

"Leadership refers to the ability to exert influence and inspire others towards achieving common goals and delivering high-quality outcomes."

So instead of focusing on traditional people management, leadership should be focused on the power of influence and the ability to guide and shape the direction of people without formal hierarchical authority.

But what does that mean in more concrete terms?

Breaking down leadership

Here are some of what I see as key aspects of leadership

1. Vision and Strategy

A leader needs a clear vision, a purpose (a why), and the ability to communicate a strategic direction to help reach that vision. The vision and strategy will inspire and motivate team members to align their efforts towards this shared objective, providing them with a sense of purpose and an understanding of how their efforts directly impact success.

2. Communication and Collaboration

Effective communication is crucial for any leader. You should be able to clearly articulate difficult concepts to expert and non-expert stakeholders and team members. Having the ability to foster open and transparent communication whilst enabling and encouraging collaboration across different roles and departments will also be crucial. To be an effective leader, you need to be able to act as the glue that will bind together everyone into a cohesive whole, all working toward the same goal.

3. Trust and Respect

Leadership requires you to build influence and credibility among team members and stakeholders. To be able to do that, you need to build trust first. This takes time but is most easily achieved through demonstrating your expertise, actively contributing to discussions, being a willing collaborator on other people's problems, and establishing a track record of making sound, well-considered decisions. By earning the trust of others, your opinions and input will hold more value. Exercising that trust well, you will build up a track record of successful outcomes, resulting in respect for your actions within others. With this trust and respect, you will be more effectively able to inspire them to act on your ideas and vision.

4. Decision Making

Leaders must make well-informed decisions that positively impact the team and project outcomes. By leveraging your respect and trust, you can guide discussions, facilitate consensus, and ensure that decisions are based on diverse experiences and considerations. Ensuring these outcomes are aligned with your vision and the business objectives will only compound the trust and respect people have for you.

5. Expertise

While not always mandatory, having strong expertise in the discipline/industry you're attempting to lead will help you speak the team members' language and further gain their trust and respect. This expertise helps them feel confident in your vision and gives them someone they feel will provide valuable insights and guide them successfully through difficult challenges. It's not always possible to have expertise from the outset, but by utilising your skills in communication and collaboration and working to build the trust and respect of your team, you can begin to learn from others and become one.

6. Continuous Improvement

As a leader, you can influence the long-term success of the team and your vision by promoting a culture of continuous improvement. You need to demonstrate this mindset yourself, being vulnerable, speaking openly about your weaknesses and how you want to address them, and seeking input from your team on how to improve. This will encourage a culture of continuous learning, experimentation, and feedback that will improve everyone's communication, collaboration and sense of team belonging. By being an example of introspection and continuous growth, you will constantly inspire the team to enhance their skills and drive excellence in outcomes.

7. Mentoring and Coaching

Leadership is about developing the next set of leaders. Leave the door open, the ladder down, and pull others up! The most effective way to do this is via mentorship and coaching. By sharing your knowledge, providing guidance, offering support, asking the right questions, and slowly delegating your responsibilities, you will empower individuals to develop their own leadership skills and expertise. This approach helps ensure that even without you, the team will succeed, and your vision will be a success.

A leadership summary

In summary, leadership is about earning trust and respect, inspiring others to act, and building the next generation of leaders. You don't need to be a hierarchical manager to do this (although, admittedly, it can help); you need to communicate well, be a good team player, and help those around you be a little better.

I asked on LinkedIn what kind of topic you would like to see me cover next whilst we wait on further progress with the initiatives we are working on at MHR. You requested me to talk about how we plan to develop our staff internally.

Companies usually focus little on growing their staff or pay lip service to it but leave it to the individual to act. There is some merit to the last part; it's much easier to help someone gain new skills if they're actively invested in it. But it's on us (the company/management) to enable the individual to become invested.

• Okay companies give you the means.
• Good companies give you the means and opportunity.
• Great companies do both and actively work with you to achieve YOUR aims, not their own.

As a company, you can do little more than give your employees the means and opportunity to learn. The key to developing a high-growth mentality (continuous improvement) in the business comes from having managers with the proper focus. The role of the manager in growth comes in three parts.

Part 1 - Provide the means

Part 1 is about ensuring individuals have access to the means required to learn. These are the very fundamentals. You must provide your employees access to the latest, highest-quality resources to help them learn.

This goes beyond a simple "you can use Udemy/Pluralsight" or another alternative. You need to factor in different learning types.

Do you expense reference books?

Do you expense in-person training events?

Do you support further/higher education?

You can't just give access to one learning platform and call it done; that's just paying lip service. Now you have given them the resources, are you giving them the time? Do you ensure every employee has the time to complete their desired learning? It's all well and good saying they can, but if you only allow them to do it out of hours, they'll be too tired to make real progress or be unwilling/unable to engage in it.

If they're attending a course, do you allow them to do so without using holiday days?

If they use an online platform, do they have enough hours during the work week to do the training without using their personal time?

There are many different ways to do this, but a simple place to start is with 10% time. 10% of their working week is dedicated to further learning, so 4 hours (half a day) in a standard 40-hour work week.

Part 2 - Provide the opportunity

Part 2 is about providing the opportunity to use these new skills. This is sometimes harder than it might sound. There are only a few opportunities to work on large projects, and other commitments have to be seen too. But this is where delegation and innovation can be your friend.

You can delegate some of your responsibilities to people who want to learn those skills. This helps you both, as it allows you to focus on taking on more responsibility while developing your natural successors.

Another option is to work with the individual to brainstorm ideas on utilising the new skills to create value for the business. The individual (with your support) can then propose and work on this new idea. This benefits the business by bringing innovative ideas and allowing the individual to use new skills in a business setting.

This is usually the point at which most managers stop. But the final part is the most critical.

Part 3 - Focus on the individual

Part 3 is about understanding the goals and values of the individual and helping to craft a path to get there, even if that means growing them toward the door.

Yes, that means supporting people who want to grow to become a manager when there is no team to manage. To grow engineers who want to learn AI when you don't have any AI products. I'd even stretch as far as helping people learn the skills to transition careers when there may not be a place for them at the company. Graphic Designer to Developer, Developer to Product Owner. Whatever that path is, your job as a manager is to understand and support the individual in attaining those goals.

I go a step further than that, personally. I encourage people to use the time to learn other skills. Your tech lead has always wanted to learn the piano ... great, support them in taking a piano class. It might not seem logical to do this, as how does that relate to being a better tech lead? But if you think about it, it's not so black and white. Learning the piano might help exercise their ability to focus and process information in real-time (reading-sheet music whilst playing) and their creativity as they compose their music. It also just makes them happy. They feel understood, they feel a sense of loyalty and closeness, and they feel supported. This is what all managers are always trying to chase, how to get their teams this feeling through their work because we all know this is the key to retention.

So, how do we do it at MHR?

MHR, well before I ever joined, has always supported people in all 3 ways. This was a critical factor in my decision to join.

• We have an internal L&D team who provide training courses in person.
• We have partnerships with 3rd party training companies.
• We have access to online training services.
• We allow the expense of training and certification.
• We use 10% time
• We don't force people to use holiday days for in-person training days.
• We are also creating our own Software Academy*.

More critically, we frequently support people in transitioning into new career paths as they want to. Many people in the company have started in one role and subsequently held multiple roles in different areas of the business.

MHR Software Academy*

I asked Ashley, our Academy manager, to expand a bit on the MHR Software Academy. Here is what he said;

It began 3 years ago as MHR realised that the global talent shortage would be an issue and the best way to mitigate it was to "Grow-Our-Own" with the introduction of an apprentice program.

We started by bringing on four Web apprentices who have now completed their apprenticeships, been promoted to Junior engineers, and are looking at the next step in their careers.

The apprentice program then extended to cover software Juniors and Graduate Software engineers joining the department, which has pushed us to further enhance the Career Development Framework already in place for all levels and ensure everyone has the tools and support to further their careers.

One of the most difficult parts of this was balancing the number of juniors against seniors without causing too much burden on them and slowing down their productivity. As part of the academy, we are looking to remove this barrier by putting in place our own team focussed on supporting the development of juniors and apprentices without burdening the product teams. We are looking to work with training providers to create a phased approach to the academy with a structured training program to upskill junior talent in our tech stack, our frameworks, and our way of working. Then start to integrate the academy engineers into the main product teams once they have grown and completed the learning required not to have a negative impact on the senior engineers.

How do you do it? How have you overcome some of the challenges we face? What else could we do at MHR? Do you have other ways to encourage and support continuous improvement in your teams?

Reach out to me on LinkedIn and let me know.

As an organisation grows, the patterns for architecture and the teams that form around them shift. It's common for this shift to cause a drift in the structure of teams and communication patterns, and the architecture they support. This is one of the challenges we are facing at MHR.

What is drift?

Drift is the separation of the intended/desired architectural design and the design created due to the communication and formation of the teams building it.

An example would be having a monolith application and a small number (3-4) of small teams (4-6 people) building it. The tech stack is simple, a back-end(BE) language and HTML, CSS and JS for the front-end(FE). Two teams are building the product, containing FE and BE engineers and separate teams for infra/ops and design.

As the application grows and we create more teams, the decision is made to move the front end onto a modern library like React, Angular, or Vue, as doing so allows you to create a central repository of shared design components. How do we do it?

Do you create a new centralised team of FE engineers? Do you create a new small matrixed team of FE engineers? Do you move the design into the Product Teams and have a matrixed team of Design and FE?

This is where drift starts. e.g., create the new shared library of code and leave the teams as they are because you want them to "own their domain". The org grows even larger, introducing more domains and teams, the communication between all these teams becomes less frequent, and there is a more significant disconnect between them, all natural growth patterns in any org. What do you think happens to the shared library?

You start to see more instances of code relating to one team and domain — a drift from the intent of a centrally shared library. If you have never heard of it, this is Conway's law in practice.

Conways Law "Organisations design systems that mirror their own communication structure."

You can break down communication structure into "team structure", "incentives", and "operating models". But for now, we will focus on the interplay between Teams and Architecture. The other aspects are articles all of their own.

You can picture how much more complicated this gets when you start to think about breaking the monolith into microservices and introducing a modern DevOps model. The amount of drift and the size of the drift can be significant. It happens naturally as the rate of change between the technology system and the teams building it are not the same. The path is not linear.

So back to MHR ...

Our Teams and Architectural drift

When the latest product was first created, it was sensibly created out of the engineering group that existed at MHR. As this engineering group built the product, they created an architecture following the desired best practices for the system and the teams based on existing structures and processes. Both sensible decisions to expedite delivery. However, this created a drift between the desired product architecture and the teams from the outset, and this drift has since grown as both the product and the teams building it have grown. It's time for us to correct this drift to allow us to move forward in the direction we want to take.

Analysing the drift

What is the drift at MHR? As mentioned in the opening article in this series, our SDLC is based on the DSDM Framework. Our teams are then built around this model. This means our teams have a Software Delivery Lead, who acts as the line manager for the team members, and the project manager responsible for delivering the work on schedule. The teams are then made up of a mixture of FE and BE engineers and Quality Analysts. All teams are then supported by a central Architecture and Platforms team. The size of the teams is proportional to the size and complexity of the product area they are responsible for. All the teams contributed to a number of repositories relating to "services" as they attempted to build a microservice-style architecture. However, the communication and operating patterns of growing teams with the DSDM framework have resulted in a more monolithic architecture than the intended design. The result is a semi-distributed code base with a lot of tight coupling. The natural result of the drift between the intended/desired architecture and how the business scaled the teams.

Steering into the drift

We've noticed a drift happening at MHR; now, how are we going to correct it? This is where many companies get it wrong. The default answer for many companies at this point is to suggest a re-org. If you're unfamiliar with the term (lucky you), it's when you take what you have, rip it apart, and rebuild it into new teams.

The problem with a re-org is that it kills team morale, breaks existing communication structures, and often results in a few people being "out of place" in the new structure. Usually, those left "out of place" are either made redundant or merged into teams with no sense of purpose, often resigning not long after. Re-orgs are complex and dangerous; they're a last resort, not the first tool in your tool belt. That's not what we want to do. Instead, we will correct our drift how you'd correct drift in a car, steer into it, making minor adjustments until you're back on track.

We're starting by adjusting our team structures to align more closely with our intended architecture. Borrowing from Team Topologies, we want to have our teams' own vertical slices of the platform and be able to deliver independently (Stream Aligned). To help us do this, we are moving teams away from DSDM to scrum (as per Part 1) so that they focus on delivering value in their product stream. As we do this, we are changing the team structures. We are re-deploying our Software Delivery Leads into positions as Agile Delivery Managers (Scrum masters) or Engineering Managers based on their background and skill sets. Depending on that transition, we will hire to fill the missing ADM or EM. Then we will break down the larger product areas into smaller ones and break apart those larger teams (10+) into two smaller (5-8) closely aligned teams (even sharing the ADM and EM where appropriate).

This aligns our team structures and communication more with our desired micro-service architecture. Small, independent teams that release and communicate change outwards without relying on other teams.

Straightening Up

You'll see how all the concepts outlined in pt.1 connect here. To straighten up the direction of travel, the subsequent correction we will need to make is breaking apart our monolithic and highly coupled"micro-services". Each new team will begin to work on doing this, taking the areas they are responsible for and transitioning them into a truly independent service so that we can begin to create the architecture to support our independent team structures. In essence, giving us independent teams working on independent services in a microservice architecture.

How we do this and identify the proper boundaries in our domain to correctly identify how to transition and split teams will be a topic for another post – assuming we do so correctly and don't "over-correct" to find we need to adjust again later. Let's wait and see.

Lesson's to learn

The key things we have identified and the key lessons I hope you can take away here are;

• Drift is natural in a growing organisation.
• Correcting drift, as you notice it, is always better than a re-org.
• Conway's law applies, and your team structure affects your architecture.
• You can't course correct all at once, you need to make small adjustments, or like when correcting drift whilst driving, you can over correct and drift in another direction.

This will likely be the first of many articles taking you through our decisions and how they play out. You will see what we did right, did wrong, and learned as we went. You can draw your parallels and get ideas for navigating these waters your way for your situation.

The problem we face

MHR is in a position that many established businesses find themselves in. We are several generations of the core product idea in, with almost 40 years of building software behind us. In those ~40 years, we have made many decisions based on the best practices of the time and the information available to us. The ever-evolving world of technology and the recent speed at which it has changed have led to those decisions creating complex ingrained patterns and ways of working that aren't conducive to the modern practices of the world in which we operate now.

We have a reasonably sized organisation of ~120 engineers split over ~15 teams. Despite the majority of these having been with the company for less than 5 years, the teams follow processes defined over 10 years ago, if not more. We are using DSDM and time-boxed delivery windows - waterfall, despite DSDM claiming to be Agile - and have recently moved from a quarter-by-quarter release cycle to a bi-weekly one. That is where we stand now—a slow release cadence and many historical processes.

Where do we want to be?

There will be no major surprises here; I don't think. We want to reach a point where we deliver value continuously. Engineers and Teams should deliver things daily in small increments of value. We want to be responsive to the needs* of our customers and be able to adjust our direction in reaction to changes in the market or in the broader regulations that are a part of our industry. We want to be agile.

* Notice that I say "needs" here and not wants. This includes an adaption to how our product org assesses and prioritises ideas. Hence, we deliver the work with the highest positive impact on our customers, even if it is not what they shout the loudest about. Proactive, not reactive.

How will we get there?

Now that's the kicker, isn't it? Figuring out how to get from A to B. We haven't yet gained full clarity on some parts of this plan. As with anything, we know there are known unknowns and likely unknown unknowns to face along the way.

It starts with boundaries. We are sandwiching this problem at first. We have gone to the upper bound and got the broader buy-in on why we want to go through this transformation, and we have set the goal to follow scrum in all product teams as our first step away from DSDM by the end of 2023. Then we have gone to the boots on the ground. We have hired a Head of Agile Transformation and Agile Coaches to help the teams transition into a new way of working. They are, in turn, partnering with each product delivery team 1 by 1 (or 2 by 2, 3 by 3 etc., as we hire more coaches) to help them transition into more Agile ways of thinking and working.

We're now focusing our attention on the filling of this sandwich. Beginning with determining what we will consider success and then how to measure the indicators of this success. I don't think anyone here will be shocked that we are starting by utilising the DORA metrics. These will begin to form/play into KPIs we will use to help drive our transformation and demonstrate our progress. No, we are not about to set ourselves up to fall foul of Goodhart's law. We're not setting goals on the number of daily deploys or specific numbers. Our goals will be focused on reducing the time to production for work and increasing the number of deployments per time period (2 weeks at first, then weeks, then days) measured in a % of our starting baselines.

That's not a very big sandwich!

No, it's not. But that is deliberate. The biggest mistake and cause of failure in these types of projects is doing too much too quickly. We could turn around and tell all the teams that tomorrow they need to use scrum and that we have set goals to reduce how long it takes to get work into production. But if we did that, the teams would struggle to operate as they try to work out scrum without support. The quality will drop as they feel the pressure to deliver faster while trying to change their ways of working. And ultimately, the effort spent on getting business buy-in is wasted as the project is pulled because the state of things is worse, not better than before.

So in the spirit of Agile. We are starting by delivering the smallest slices of value we can in our transformation journey. We are gathering data, assessing our options, what delivers the next most valuable change, and then going around again. After all, it would be heretical to deliver an Agile transformation in a waterfall approach, wouldn't it?

What's next?

I can't tell you exactly what will be next up for us in our transformation. Or when the next learning will come. However, I can talk a bit about one topic - Team Structures. So expect another post in the next week or two talking about Team Topologies and how your system design impacts your teams and your teams impact your system design.

It's a common request for many managers. "Please improve the team's level of productivity." Sounds simple enough, right? The simple answer is no. No, it is not simple in the slightest. In this article, I will explain productivity and give you some best practice advice for measuring what you can. Let's begin ...

What is productivity?

Productivity. You will probably hear a few variations on what it "means" regarding software engineering. But its literal definition can be defined like this.

The effectiveness of effort as measured in terms of the rate of output per unit of input.

In layman's terms, it is the ratio of the number of things in compared to the number of things out. The more you get out for the same amount, the more productive you (or your system) are. It should be simple to measure an engineering team's productivity. The amount of work produced is divided by the number of people it takes to produce it. But hold on a second, how are you measuring the work produced (output)? And what are we measuring against (input)?

What is our output?

Many of you have already started thinking about story points, tickets closed, and other seemingly obvious choices. But let's step back and think about it for a moment. What are we really trying to measure? We want to measure business impact. I'm sure none of you would put your hands up to tell me you churn out any old thing. You create work items to deliver features which have been determined to provide some value to the customer. But now it gets complicated. How do we measure business impact? How do we correlate new or increased business revenue with a particular feature released on a particular day, built by a particular team? Put simply. You can't. We need a proxy measure. We will return to this in a moment, but before we do, I want to talk about our Input, arguably the simpler of the two.

What is our input?

We are going to find a suitable proxy for our output. But before that becomes useful. What is our input going to be? A person? A unit of time? Most people default to using both and picking the number of hours worked by individuals as their input. Seems like an obvious choice. But it's wrong for a few reasons;

1. Our productivity is now relative to single people. This might be manageable for 6-8 people, but imagine doing this for a 200+ strong org!
2. A very simple one, people don't like it. Start tracking everything they do if you want a surefire way to piss off your employees. Big brother much.
3. How do you account for holidays? Half days? Illness? Not only that but how do you measure what hours count? Meetings? Context switches? Coffee breaks? It's already gotten messy.
4. You are inadvertently penalising some of the most important people on your team. The "glue". Those people spend most of their day pairing, passing on knowledge, unblocking others, reviewing code, and attending strategy sessions. Your most senior engineers are going to look like your least productive.

I'm sure you get the point. But you were right to think about people and time as a single input. You just zoomed in too far. Software engineering is a team sport. You need to measure teams. Measuring teams remove the considerations about holidays, how days are structured, or what type of work individuals do. And instead of hours, you want to measure in days. How much does 1 team produce in 1 day?

The only time you might consider "people" in this equation is if you're micro-optimising and want to compare the productivity rates of teams based on team size. How does a team of 5 compare to a team of 10? for example. But that is an edge case, and you still measure the team; you compare relative output ratios against total team sizes to see if there is a trend.

Picking your output proxy

Now that's out of the way, we are back to the original thoughts about our output. We know we aren't measuring our actual output (value created) because we can't, which circles back to measuring the number of work items delivered. Before you run off and start creating a dashboard to track work items completed over time, remember a golden rule "You get what you measure". Or, to quote Goodhart's law

"When a measure becomes a target, it ceases to be a good measure."

And to repeat what I said earlier, "I'm sure none of you would put your hands up to tell me you churn out any old thing." And if we measure work items delivered, I guarantee that is what you will get, more random tickets in your system like: "Email Bob about question" and "Write documentation", and your work items will be made hyper granular "Create File", "Add code to file", "Create Test", "Write Test", "Run Tests" etc. etc. Ok, maybe that is a tad extreme, but you get the point; if you tell people that tickets done is the thing you track and that you want them to get more tickets done, they'll do it by creating more tickets, NOT by doing more work.

So, what the hell do I measure?

The answer is that you don't measure things in isolation. You measure relationships, and you measure trends. You measure instead things like the number of work items done in relation to the number of software releases, and the number of software releases in relation to the number of bugs/errors found etc. This way, you can see things like, we are delivering more tickets, but that isn't impacting releases (are we doing too much toil?), we are releasing the same, but our error count is going up (why is our quality dropping?).

This is where there are well-established best practices to help you out. The big one, and the first one I will mention, is the DORA metrics. DORA stands for DevOps Research and Assessment (Group), which is part of the Google ecosystem of companies. They used extensive research to determine a set of measurements that can be reliably used to determine a software company's performance (and relative success).

The DORA metrics

I won't go into much detail here, as that isn't the article's point. However, I will summarise the metrics you will measure;

• Deployment Frequency: How often you make successful software releases to production.
• Lead Time for Change: How long it takes to get from committing a code change to that code change being in production.
• Change Failure Rate: How often a deployment fails or a software change results in a failure in production.
• Mean Time to Recovery: How long it takes on average between an interruption from a deployment or system failure for the system to fully recover.

You can use these as an excellent proxy measure for your team's productivity. You want to see a high deployment frequency, a low lead time for a change, a low failure rate, and a fast mean time to recover. You will measure the impact of changes by watching the relationships with these measures over time.

Awesome, thanks!

So that is the bare bones, a simple way to measure productivity. But before you run off in celebration, there is more. Just utilising DORA alone leaves a lot of opportunity on the table. Let me take you into SPACE 🚀

I always wanted to be an Astronaut

SPACE ... the great beyond ... at least the great beyond of DORA. DORA is fantastic, but it completely ignores a considerable portion of how we perceive and measure productivity. If I casually drop in the word "flow", I'm sure you all know what I mean. That state of deep focus where the time goes by, and you solve your biggest problems and challenges, and it just feels easy. That has an obvious link to productivity, but how satisfied you feel also correlates with productivity (link). And this is where the SPACE framework comes into play.

Welcome to SPACE camp cadet!

So what is the SPACE framework? SPACE is, unsurprisingly, an acronym for the 5 different metrics you are looking to measure.

(S) - Satisfaction & Well-being:
How fulfilled the engineers feel with their tools, team, culture, and day-to-day work; How happy and healthy they feel and how their work impacts them.
‌(P) - Performance:
An outcome of a system or process.
‌(A) - Activity:
The number of actions or outputs completed whilst performing work.
‌(C) - Communication & Collaboration:
How individuals and teams communicate and work together.
‌(E) - Efficiency & Flow:
The ability to complete or progress on work with minimal interruption or delay caused by people or systems.

These can seem like very "woolly" or "grey" areas to try and measure, and they are, but it's such a significant topic that it will be better served by a follow-up post of its own.

For now, here are a few simple examples of measurements, all at a team level;
(S) - Averaged Developer Satisfactions Scores (eNPS)
(P) - Change Failure Rates
(A) - Deployment Frequency
(C) - ‌ PR Review Times
(E) - Lead time for Change

Conclusion

So there we have it. Measuring the productivity of development teams is hard. We can't measure our work's true impact (outcome) and must be careful how we proxy it. But by using DORA and SPACE, we can have some good insight into how productive our teams feel and how efficiently they can operate. Remember, measure the trends over time, and DON'T MEASURE THE PERSON!

This is what happened to me, and this is my honest account. Unlike usual, this article will be more based on my experience and opinion than on offering concrete advice. So for those who read my work purely for its educational value, this one might not be for you.

Setting the Scene

Let me set the scene. I have been through redundancy and have spent a long time looking for the next right role. I've cut a substantial amount off my wage (over £30K), and I've already dropped my expectations in keeping the same levels of seniority (I'm a senior technology leader). I've widened my bucket as far as I can afford to. And I'm getting desperate. My run-way of savings is at an end. Things are bleak ... then tada 🎉 A company I had applied to at the start of my redundancy (3 months ago) finally got back to me. Everything is looking up again. They moved quickly; they kept the interviews short, 2 of them 1.5 hours in total. They made an offer the same evening after the final interview and sent the contract through at 22:00.

Did you see it?

Now, there were already a few warning flags that I completely ignored because of my situation. Did you spot them? It took this company 3 months to respond! There are clearly some issues happening within this company if a 3-month lead time is an acceptable thing. Then the sheer pace of it all, only 1.5 hours, all done, meeting just 3 people for a senior leadership position? That's not very thorough; they were as desperate as me I think. I had mentioned that I wanted to move quickly as I was in the final stages of another company, but still, that's obscenely fast. If that wasn't enough of a flag, getting the contract sent out at 22:00! That's not normal, not a bad thing just on it's own, but given the rest of it, its a flag they're desperate for a bum on that seat. This role was sold to me as one with autonomy in a company that values technology, values people, and has a clear mission. I, also in a hurry (I'm not an innocent party here), didn't ask thorough questions, took what they said at face value, and even flatly ignored some negative Glassdoor reviews about the things they were claiming to be the opposite. Doh! Rookie move.

Once on the inside

Once I had accepted and started - which wasn't a smooth, easy thing, but moaning about onboarding is a different topic to this - what was it like?

No prizes for guessing here. It was chaotic, not quite world on fire, but not far off. This should have been obvious given the warning flags I ignored during the hiring process. So I was thrown in with no clear direction, no product ownership anywhere in sight, no data to speak of to make decisions, and a new set of priorities every week. Now ... this company was/is still young, so the idea of many people wearing many hats and shifting priorities is to be expected. After all, that is the nature of a start-up. However, the difference here, in my experience, is normally a start-up has a clear vision of where it wants to go and what it wants to achieve. It has some measurements to determine what aspect of its product is working and what isn't. That is what drives the changes in priority and direction, data. All of that was absent. This was all guns blazing doing things prioritised by who can shout the loudest. No body really knew why they were doing what they were doing. If any of you have read the Phoenix Project ... you get the idea (and if you haven't, you should). It's not quite as bad as it was at Parts Unlimited, but there was a clear familiarity.

Now the naive part of me thought, "Great! Chaos! No product ownership. I can have a huge impact here and start to right this ship. Product, process and people are my thing!" ... Wrong! The company can't or won't allow the fast adoption and trial of tools (budgets, regulation, politics? Not sure I never worked that out). So that's my plan scuppered already. I have no data, and I can't get access to the tools needed to gather that data.

The ol' bait and switch

The next trap I had seemingly fallen into was the old bait and switch. I had been brought in with the promise of one thing and had it replaced with something else before my feet had even touched the ground. It wasn't all bad news; my manager* was very wary of the same problems and the fact everyone was running around like a headless chicken. They arranged an "offsite" to talk over priorities. So at least, we should be able to start to see what needs to be done now. In the interim, I stepped into a new role as backlog administrator and project planner (Interim Product Owner) of sorts for some the established teams. After all this, we identified a key problem, recognised it as a priority, and tied it back into the business. Onwards and upwards?

* Credit where credit is due. My manager was and is badass at what they do.

Yeah, but no, but

We have a priority; we have an agreed direction. We started to create a backlog of work; we created a hiring plan. We needed an SRE team. I wasn't hired to lead SRE; I have no experience with SRE hands-on. But you know what, I don't mind a challenge. Then it's casually dropped in; we can't call them that, and we can't position it to the business as that. Ahh, politics, how we love you. So I set about resourcing, reaching out to my network and so on. We even start to interview for the roles. Does anyone want to guess what happened next?

Deje Vu

Before that entire initiative ever gets too far, priorities shift again. And we are back to the original remit. You know what? It's been a massive waste of time, but at least I'm being told to focus on what I was initially hired to do. Great, time to crack on. By this point, I'm a bit fed up; I'm tired of a lack of direction in the business; I'm tired of the politics and how it seems to be grinding things to a halt, I'm starting to spot other red flags in senior leadership. And then something happened. Another recent hire, a senior leader, far more experienced than me and more familiar with the industry and regulated spaces, announces they're leaving because they're just going to clash heads with the people they need to work with. They'd been there for about 4 weeks. Now I'm starting to question what I'm doing. Should I stay? Or should I go? (Spoiler I should have gone).

The machine the cog and the hamster

Not long after this, I started to get a better understanding of who is who and how things are run. And this is where I start to see other issues. This company is supposed to be remote first. Yet every day or two, I need to remind people of this. Not just other engineers. I'm reminding HR, Marketing, and other Senior leaders. There is a clear bias toward office attendance, and there is a clear clique and "inner circle" of those who attend the office frequently and those that don't. There is also a problem with on-call, and the answer wasn't to hire a team (we did need that SRE team) whose role was to take on that responsibility as first-line. Nope, the answer was moan about a lack of "commitment", debate if to pay people more than the base amount already on offer for on call ... oh and to make it mandatory for everyone. Sod your work-life balance, make it mandatory and part of the career progression framework for engineers ... Hi Elon! Nice to meet you. That's just a slice of the pie, but enough to show a drive towards the much hated "hardcore bro culture" often associated with software engineering.

Hold yourself accountable!

Now, I'm not going to pretend that I'm innocent here. Ignoring the fact that I missed a lot of cultural red flags before starting. I also then continued to try and stick around "to add another string to my bow" whilst going against my instincts. Whilst in the role, subsequently, I didn't perform to my best. I couldn't get my head into it. I couldn't get behind the product. I couldn't get behind the leadership. I was not motivated. I was failing to do things I would expect of myself as a leader. I could have tried to win over hearts and minds, and be more proactive with my dissenting opinion. I could have gathered data, given presentations, driven my own initiatives. But I didn't. They're things I have done in the past. But I just didn't have the motivation. I wasn't bought in. I was trying to fake it till I made it. I just didn't fit in, and I knew it.

Don't get me wrong; I'm not suggesting I was lazy. I put a lot of effort in to the things I was doing. Into hiring, reaching out to my network. I put a lot of effort into considering and researching different methodologies, processes, and schools of thought in improving developer experience. Ultimately they needed me to show I was doing something by creating presentations on roadmaps (which I hate to do without data and a clear purpose), not just doing things behind the scenes, and they needed me to be more aligned/involved with the rest of the leadership team. But I just had no desire to become a part of that circle, it was an echo chamber that knew what and who it was, and was happy with that. There is disagree and commit, and then there is breaking your own values. I could have done some of these things they needed of me. I could maybe of tried harder to find a way to fit in without doing things I disagreed with. Maybe you could accuse me of being closed minded, and being closed to their view, after all, they have driven the company to profitability. But this the whole point of this article. Culture, or the perceived culture, changes everything. Being in the same situation in a company where I felt a part of it, where I felt aligned to where they wanted to go (even if they're not there yet), this would be a very different story. In fact it has been a different story in the past. I'm sure it will be again.

The lesson!

So the simple lesson here is. Please don't hang around. There is no shame in admitting when a culture isn't right for you. Don't work for or in a culture that doesn't align with your values. You can twist any company value to align with your own. The question is, what does that value mean in reality? Are they living it? Does it align with your version? If the answer is no, get out. I stayed, made myself stressed and unhappy, under-performed, and ultimately ended up agreeing to leave during probation. Nobody won in that scenario.

Following on

To add some additional information to this, and to show it's not a hit piece (why it's all name-less) or just a bitter man's opinion. I have spoken to multiple people at the company to get their take. Some of these people have been with the company for years, and some for less time than I was. Some of them plan to leave, others plan to stay. But here are some key takeaways from people who also probably don't fit the culture and how it feels to them;

• Ignoring toxic behaviour and sweeping it under the carpet when an individual has a perceived high value.
• A lack of feedback.
• Using an individual’s weaknesses against them to prevent them from succeeding.
• Setting individuals up to fail by providing no feedback and not setting objectives.
• Recruiting without due diligence and firing people early into the job.
• Not displaying their own company values.
• Being a remote-first organisation but taking a leaf out of Elon Musks' book. (This wasn't my quote, I promise).

This shows lots of people are seemingly willing to work for companies where they don't fit the culture. I have no doubt some people will love it and thrive their, there are some very competent leaders in the business (my manager was one of them). But when you don't feel like the culture is right, that you feel out of place, and you think "Should I stay or should I go?", the answer is almost always universally, go! You only get to live your life once, and you spend a lot of your adult life working, so don't make yourself unhappy, ind somewhere where you feel at home and move on. There is no shame in it!

When you don't understand how different people prefer to communicate, effective communication is almost impossible. In this article, we will explore different ways of communicating with your team and discuss who should be responsible for ensuring that the message is understood.

Who is responsible for ensuring the message is understood?

The whole point of communicating with someone, no matter how you do it, is to convey a message of some kind to that person. We all understand that, we have done it all our lives, even before we could talk. So who is the onus on to ensure that message is understood correctly, the person doing the communicating, or the person receiving the communication?

I don't think there will be too much shock or uproar by me just stating it's the person doing the communicating that is responsible for ensuring the message is understood. But that leads me straight to the next question ... why do we not care?

Why don't we care if people understand us?

This might seem like a flippant question. But it honestly seems to be true. You could easily argue (as you'll see in a moment) that I don't right now. We all seem to understand that it is on us to convey our message in a way that is understood. Yet we all seem too default to defining that as one thing. It might be, speaking clearly on a call, writing a clear message, or writing a clear email. But as we all know, not everyone is the same. You'll know from some of my other articles, I'm a big fan of Myers-Briggs personality types. And you will know how they impact different learning styles from my article on spotting stressed employees. So it's not unreasonable to also assume that different people on your team are going to need to receive information in different ways.

Getting a lay of the land!

As a manager, we are naturally going to have a bias in our default ways of communicating. For me as an Introverted Thinker, I like to give and receive information in written form. So I will likely default to sending you a message in Slack/Teams. And if I don't use an Instant Message, it's probably going to be an email. But that is my bias. I know all too well that my wife's preferred method of receiving information as an Extroverted Feeler is verbal. So if we were working together, she would much prefer to have a chat about something on a call or in person than to get a written message.

Knowing this, the solution to ensuring you communicate the right way with someone is pretty simple. Ask them.

In your next 1:1, if you don't already know, ask your report how they prefer to receive information from you. Do they want a quick direct message, a lengthy email, a phone call, a video chat, or some other method of communication? Take note of it, and try to use that method when you need to convey a message.

Hold up! It's not that simple ...

What if I need a paper trail for HR? What if I'm communicating with a team of 20 people? You can't create and give a custom message to every single recipient!

And I wouldn't expect you to. For one, that is very likely to result in people having different understandings of the message. And that is a very bad thing. This is where you need to start to think more strategically. How important is this message? How complicated is the topic at hand? In most cases, you can convey the message in a way that gives everyone the best chance of understanding. So here is my framework for choosing how to send out a communication;

Picking the right ways to communicate.

How many people am I communicating with?

First off, am I communicating with one person, or with multiple people?

Multiple People.

When talking with multiple people, to ensure it's understood by everyone you should use all the tools at your disposal.

1. Send out a group message letting people know you're about to send an email and include any resources for them on the subject that are available.
2. Send out an email inviting them to attend a meeting, and re-including the same resource links as the message.
3. In the calendar invite include a summary of the meeting purpose, the agenda, desired outcomes, and again, links to the resources.
4. Have the meeting, take notes (or assign someone else to) and record the session.
5. Afterwards, put the summary notes and recording into a document in a shared space (Wikis are great for this)
6. Send out an email and group message to thank people for attending, summarise the agreed actions (or decision(s) taken) and a link to the document containing the notes and/or the recording.

Congratulations, you have thoroughly covered all methods of communication, and have a solid audit trail of decisions made and why.

A Single Person.

Firstly, does the type of message need an audit trail (HR/Legal reasons etc)? Secondly, how does the recipient like to receive information?

An audit Trail is needed.

Prefers written comms:

1. Send an email (which is best for audit reasons)
2. Send a direct message summarising the email letting them know it has been sent.
3. Try to converse via email.

Prefers verbal comms:

1. Send an email inviting them to a meeting, summarising the purpose of the meeting.
2. Record the meeting (for audit reasons)

No audit needed.

Prefers written comms:

1. Send them the message by whatever written communication channel they prefer.

Prefers verbal comms:

1. Give them a call, or arrange a meeting however they prefer.

It might seem like a lot of effort to go too. But trust me, it saves far more time going to these efforts than it does re-having meetings to correct misunderstandings, fixing legal problems because you don't have an audit trail, or correcting the bad outcomes of making poor decisions.

As the saying states "Go slow, to go fast".

Now I guess I should go and turn this into an audio recording to take my own medicine right? ... 🤔

I'm sure many of you have already heard or come across the Myers-Briggs model. It's a simple model of patterns and biases in human cognitive processes that help identify and group people into different types of personality. I like using the 16 Personalities platform and its expansion upon the traditional Myers-Briggs model. However, the basis remains the same. The model will explore and identify different base traits of your personality;

1. How you interact with your surroundings. Are you more introverted or extroverted?
2. How you process information and see the world (how you learn). Are you more observant or intuitive?
3. How you make decisions. Are you more of a thinker or a feeler?
4. How you plan and respond to change. Are you more organised or more flexible?

From these base traits, it's possible to categorise yourself as fitting most into one personality type. This isn't to say you are 100% one thing, all humans are flexible and may show traits of many different types of personality. This will just help you identify behaviours that you are "most likely" to exhibit.

What does your personality type have to do with stress?

Naturally, you are probably now wondering what your personality type has to do with stress. And even more importantly, how your reports' personalities are going to help you identify stress early. Luckily the idea is pretty straightforward. From the above model we can identify two key aspects of being human;

1. How we learn
2. How we make decisions

We also need two more key things to be a well-rounded human;

1. The ability to get in touch with our "inner self" (An Introverted part of us)
2. The ability to express and receive feedback from the real world (An extroverted part of us)

Using the traits listed above and our personality type, we can identify the four main cognitive functions that will influence our behaviour.

The four horsemen of behaviour!

The most common way to understand these four cognitive functions is to imagine a car. In this car, there are 4 people. The first person is the driver. This is the person that is in control of where the car goes. The second person is the co-pilot. This person supports the first person and helps them decide where to go. The third person is the passenger. This person is just along for the ride and has no special purpose. The final person is the baby. This person is silent until something goes wrong, then they start screaming, and both the driver and co-pilot become distracted and the car no longer does or goes where expected.

It's the screaming baby you need to learn to identify, and to identify early, to help reduce your reports' stress levels.

I'll use myself here to help paint a more concrete picture. I'm an INTP personality type. This means that I'm naturally more introverted than extroverted, I rely more on my intuition (gut feelings about what will happen) than my observation (what is happening right now), I'm more of a thinker than a feeler (I'll try to solve problems rather than acknowledge feelings), and I'm more of a prospector (improviser) than a judge (organiser). So let's dive in;

Figuring out your two "favourite" functions

Going back to our aspects of being human. We can see from my personality type that my preferred way of learning is via Intuition (N), and my preferred way of making decisions is via Thinking (T). Each personality type will then naturally have a preference as to whether they prefer learning or making decisions. Depending on yours, this will impact your Driver and Co-pilot functions. If your driver is learning, your co-pilot is automatically decision-making, and vice-versa. The way you learn (Intuitive, or Observant) is called your "Perceiving" function. This is how other people perceive your behaviour. So by extension your learning preference is an extroverted function.

This means I have "extroverted intuition". Again using the aspects of being human from above, this only completed one-half of me, meaning by extension, my means of making a decision, is Introverted Thinking.

Who's Driving?

To determine which of these is your driver, and which is your co-pilot, you need to look at the first letter of your result, whether you are more of an extrovert or an introvert. I'm an INTP, which makes my Introverted Thinking my driver. And by proxy, Extroverted Intuition my co-pilot.

How does this play out in the real world?

Before we look at the passenger and baby, let me quickly explain what that means in the real world. In essence, my primary function is introverted thinking, this means I'll get most of my "work" done in isolation, by thinking over problems and solutions in my head. Once I have reached a decision you'll see me express it as a statement of fact that I believe this is the best way to go. I probably won't have any data to hand, and I'll probably use phrases like "I think this is the best way to go". To demonstrate the opposite, an Extroverted Thinker would likely talk through every idea and solution out loud with you and others, but would then make the decision internally, and proceed to take action without ever letting any of you know.

The passenger and the baby

So how do we determine who is the passenger, and who is the baby? In our car, the passenger sits behind the co-pilot, and the baby sits behind the driver. The reason for this, they're the exact opposites of the people in front of them. So continuing to use me as an example, my passenger is Introverted Observation, and my baby is Extroverted Feeling.

Spotting stress by listening for the crying baby.

Spotting stress in your reports when you have figured out their personality type (it's super easy if you ask them to take the test 😜) becomes quite straightforward.

To use me as an example; Someone who ordinarily isn't very chatty and vocal, and is usually very logical and reasoned. When this person starts to become stressed, the baby starts to cry, and that Extroverted Feeling starts to come out. At first, it might be a snarky comment or a usually unvoiced grumble of decent, but after a while, if left unattended, it can become a full-on tirade of highly emotive outbursts, that may seemingly come from nowhere.

Luckily for a manager, I'm an easier type to deal with, because as I become stressed, I become more vocal and more emotive. That's an easy one to spot. But what about someone who is normally an Extroverted Feeler? They'll start to become quieter and more logical, which can be hard to spot and is certainly easier to confuse with someone who is just working hard to solve a problem. Or how about even someone who is ordinarily an Extroverted Perceiver, someone who is vocal and flexible? How do you spot when they become less vocal and are all of a sudden planning everything to within an inch of its life, and possibly even to the point of analysis paralysis, but without ever telling a soul?

It's not always obvious when things are bordering on the crying baby, and when someone is utilising an often under-used part of their toolkit. After all, no one is 100% one thing or the other. But what using the Myers-Briggs and the four functions model does, is it allows you to better understand your reports, and what is "normal" behaviour for them. Using that tool kit you can sport earlier when someone is behaving out of character and showing signs of stress, meaning you can reach out, and speak to them. "Hey, you're being quieter than usual at the moment, are you ok?", or "Hey, you seemed to get more visibly annoyed during that meeting than you would normally, is everything ok?". It's never a diagnosis, it's just a conversation starter.

Now go forth and reduce your teams stress! Good luck.

Every software engineer should be familiar with their team's API. Their team's API is what other teams will use to interface with them when designing and building solutions. It is their boundary of responsibility and it is the first line of defence against scope creep. In this post, we'll discuss why it's so important to define your team's API and how to go about doing it.

Why You Need a Team API

A well-defined team API serves a number of purposes. First, it provides a clear boundary of responsibility for your team. Other teams know exactly what they can and cannot call on your team for. This prevents scope creep and keeps everyone on the same page. Second, a team API provides a consistent interface for how other teams should interact with your team. This means that there are fewer surprises and fewer opportunities for things to get lost in a backlog or ignored entirely. Finally, a team API makes it easier to onboard new members of your team because they have a clear starting point and a clear understanding of what their responsibilities are.

How to Define Your Team API

There are a few things you need to keep in mind when defining your team API. First, you need to think about what other teams will need to interface with yours to do their jobs. What information will they need? What specialist skills will they need? Who will they need to talk to? Second, you need to think about how often other teams will need your team. If it is only occasionally, then you can get away with a simpler API. However, if other teams will be relying on your team daily (Platform/Infrastructure teams I'm talking to you), then you need to make sure that your API is robust and easy to use. For example, a simple Design System teams "API" might be something like this;

"We are responsible for the creation and maintenance of components within the design-system repository. We are responsible for fixing problems within the components themselves, but we are not responsible for debugging and fixing issues by integrating them into the solutions of other teams. If you have a feature request or would like to report a bug, please raise a ticket following the process outlined in this document <Rasing a feature/bug request>. Any requests sent directly to engineers will not be actioned, and you will be referred to the above process. For any P0 requests as defined in our SLAs (<Design System SLAs>), please raise a ticket using the above process and escalate it to <Team Leader> in the public team channel".

For a more in-depth API I recommend doing the following steps;

1. Define the Problem

The first step is to sit down with your team and identify the areas where there is confusion or ambiguity about roles and responsibilities. What are the questions that people are constantly asking each other? What processes are taking longer than they should because people don't know who is responsible for what? Answering these questions will help you to identify the areas where your team's API needs to be better defined.

2. Draft the Solution

Once you've identified the areas that need work, it's time to start drafting the solution. This will involve creating a set of expectations for each role on the team. What are the core responsibilities of each role? What are the boundaries of each role? What is off-limits for each role? Answering these questions will help you to create a clear and concise definition of each role on the team. You can then uplift these responsibilities into your team API, and provide a guide on SLAs for different types of requests. Be careful not to expose who will handle each request type, especially if there is only 1 person (you might have a skills problem if that's the case), as you don't want people to bypass your process and go straight to engineers. Then you can't keep track of how much ad-hoc non-project work your team gets asked to handle.

3. Implement the Solution

The last step is to implement the solution. This will involve communicating the new expectations to all team members and making sure that everyone is on board with the new way of doing things. It may also involve making some changes to processes and procedures so that everyone is working within the new boundaries that have been defined. Once everyone is on board, it's time to start reaping the benefits of having a well-defined team API by shouting about it to the wider engineering organisation and giving your team the autonomy to ignore requests that do not follow the agreed processes.

Conclusion

Defining your team's API is one of the most important things you can do as an engineering leader. It sets the boundary of responsibility for your team and provides a consistent interface for other teams to use when interacting with yours. When defining your team API, make sure to think about what other teams will need and how often they will need it. And finally, make sure to talk to your team about what they need too.

Too often, engineering teams are far removed from their customers and have little understanding of what they are doing or how they are using the product. This can lead to a lot of wasted time and effort, not to mention frustrated customers.

Why is a product mindset important?

In a fairly common team set-up for most organisations, engineers often look at the product owner as the source of truth for what they build. They get handed tickets with crafted stories and a set of criteria for what the thing they build should do. They then see their job as taking these criteria, translating them into a set of technical requirements, and then writing software to meet them. I'll put it flatly ... this is wrong.

To be able to build an effective solution, you first need to understand the problem. The product owner isn't the person facing the problem, the user is. To be able to solve the users' problems effectively, you need to understand them, and what they want and need to do. This isn't to poke holes in the Product Owner, but they won't be able to fully take the evidence and client input they gathered and turn that into effective software. Chances are they may well miss things a software engineer would consider vitally important to know. I say this a lot, but it's worth repeating, writing good software is a team sport!

The product owner and software engineering team should work closely together from the start. If possible having an engineering representative on a call with the client as well as the product owner would be perfect, but even if not, the very next step they should certainly be involved in.

Non-function requirements ... they're a very important thing in writing good quality software, and something that a product owner may overlook. They're the things like, is it more important for this to be fast, or for it to be reliable. It's not a pure one-or-the-other scenario, but to an engineer, this can be the difference between choosing a cutting-edge technology or design to get the fastest possible performance or picking an old well known and very slow-changing technology that is known to be highly reliant. The classic product viewpoint is that speed is important, users don't like things to be slow, data will show drop off if it's not a sub-1-second request etc. However, it may be that this data is a legal requirement, and can't be dropped or malformed, in which case, speed could be bad, and speed could be risky. In this case, it may be a chance to build a technical solution that provides that stability, and to partner with User Experience experts to determine how to best give the perception of speed, or the confidence something is happening.

Thinking about the user, and their problems is a key critical skill in being able to write good software solutions to problems. This skill is often underdeveloped in engineering teams with a poor product mindset. They act like they're part of an assembly workshop, not a creative problem-solving team.

Product mindset = Job satisfaction

Another great added side benefit to having a product-focused engineering team is that we can close the feedback loops. The engineers are closer to the customer and get to see and feel the difference their solutions made. It's far more satisfying to get feedback that tells you something like "Feature X saved me 2 hours a day on Y repetitive task, it freed me up from working longer hours, and means I get to see my children before bed" than it is to be told something generic like "Customer satisfaction increased" or even worse ... nothing.

Lo and behold, when engineers start to get this first-hand feedback and see their positive impact, it drives them to become even more involved in the product, and in solving the users' problems. They start to think like the user and make suggestions to improve the product with the user in mind. It increases innovation. It increases customer satisfaction. But most importantly, it is going to increase your retention in your teams. That sense of impact, that tangible recognition of their work, breeds a sense of purpose and belonging, and believe it or not, even your most head-down headphones on the engineer is a social being. Those things make people stick around.

How do I build the product mindset

Building a product mindset in your teams could be either a very simple thing or a very complex thing. I'm afraid it will depend entirely on your company and situation. The principle at heart is very simple though, work together more, work together sooner. Get the people involved in building the software involved from the very beginning, from the requirements gathering with the user. Work closely with each function in the business to ideate, define, and deliver the solution. Track how that solution is used, and how it is performing (user analytics through to technical observability). Then gather feedback using whatever tools you have available, and make all this information available to everyone on the team.

To do this, you can just follow healthy best practices, I'd advise using Extreme Programming best practices to help shorten feedback cycles. Make sure conversations are centred around the user and focused on delivering value to those customers. Sure, we are building something technical, but it doesn't matter how great a technical solution is ... if the user isn't happy and doesn't use it. To borrow a classic statement ... User first, always!

I hope this short article helps you think a bit about how you can start to create a more product-centric mindset in your engineering teams, and why it would be beneficial to your team and company to do so.

When we think about good communication, we often jump to the same two points; How clearly am I speaking? And, How clearly am I writing? But communication is about far more than just those two aspects. Although important, they fail to address some more critical aspects of effective communication. So what does good communication mean?

Good communication is made up of multiple concepts and parts. It is about;

• Removing friction to understanding
• Removing confusion
• Simplifying complicated topics for easy digestion
• Being proactive in communication
• Using the correct means of communication
• Listening/reading
• Speaking and writing clearly

In software engineering, there can be a lot of moving parts and often times team members are located in different parts of the country if not the world. It's therefore important to have systems and tools in place that facilitate good communication between team members, and this goes beyond email and chat facilities like Slack or Teams.

Good communication is something that needs to be embodied into your company culture, and the earlier you set this standard of behaviour the better. The good news though, is that, unlike some things, this can be remedied.

There are a few key things you can do to improve communication within your team:

1. Encourage and practice active listening (and reading) - this means really hearing and understanding what the other person is saying. It requires being present and not letting your mind wander. This is probably one of the biggest things in good communication, you'd be amazed to see the improvements made when people start actively listening. It's undoubtedly one of the hardest ones to master as well.
2. Make sure everyone is on the same page - this covers the removing confusion part. Regardless of whether the communication was verbal, written, or other. When the discussion approaches what appears to be a conclusion, take that appearance with caution and review the discussion, key points and any outcomes. There is nothing worse than 3 people taking away from a discussion 3 different visions whilst believing they're all in agreement.
3. Address the right audience in the right way - I'm sure it has happened to you; you have been in a meeting where someone has spent half of it explaining something that only needed 5 minutes. And the opposite, where someone has glanced over a topic in 5 minutes and assumed you know all the details. Both leave you feeling confused or annoyed. And both cause you to lose attention and stop actively listening. So before you dive into the technical details of a project or choose to glance over deep implementation details, assess your target audience and ask yourself this question; What is the least information needed to convey the point and achieve shared understanding?
4. Use the right tool for the job - We have probably all said, "that meeting could have been an email". It's true; if you want to ensure that your communication is well received and understood, consider the medium in which it is delivered. How urgent is this? If it's very urgent, it should probably be a video/voice call, and if it's not urgent, it might be better as an email, a document, or a message in Slack/Teams. How detailed/complex is it? If it's very detailed/complex, maybe it should be a document first; give people a few days to read it, then follow up with a meeting or a channel/thread in Slack/Teams. How transient is this information? If this information is not going to change, a document would probably be best. Still, a voice/video recording could be a great adjoining way to communicate to allow for other learning styles. People often default to the meeting without considering its actual value. Before you arrange that meeting, send that email, or blast that group chat, think about what it is you're trying to achieve, and pick the solution, or solutions, that are going to support your aims whilst respecting your colleagues' time.

You can also foster and improve the communication culture in your software engineering org by utilising other more engineering-specific concepts. For example, Extreme Programming principles like Pair and Mob programming can take your team communication from "Okay" to "Outstanding". You can read more about that in my article, "Using extreme programming to build a strong, scalable team culture".

cccccbctejteSo there you have it, a quick and dirty guide to improving the Art of communicating well in Software Engineering.

In this blog post, we will look at how Extreme Programming (XP) practices can help build a Culture of Trust that encourages open, honest communication and high levels of innovation.

So what is Extreme Programming?

Extreme Programming (XP) is a software development methodology first coined in 1996 by Kent Beck. It is based on the principles of Simplicity, Communication, Feedback, and Courage. XP has been used successfully on large-scale projects such as Microsoft Windows 2000 and XP, Adaptive Path's Manifesto project, and Chrysler Comprehensive Compensation System.

Extreme Programming practices are designed to address the challenges that software engineers face when working on complex projects. These challenges include:

• The need for speed: In today's fast-paced world, it is important to be able to get products to market quickly. With XP practices such as continuous integration and automated testing, software engineers can make changes to code and immediately see the results. This helps reduce errors and get products to market faster.
• The need for quality: In order to be successful, software products must be high quality. XP practices such as test-driven development and pair/mob programming help ensure that code is of the highest quality before it is released to customers.
• The need for flexibility: As customer needs change, so too must the software that they use. XP practices such as refactoring and customer collaboration help make sure that code is flexible enough to meet changing needs.

Ok, great, we now know what XP is, but what is it not?

So what is Extreme Programming Not?

Extreme Programming is not a silver bullet. It is a software development methodology that can be used well or badly. XP is not scrum. Scrum is an agile software development methodology that was created in the early 1990s by Takeuchi and Nonaka. While XP and Scrum share some common practices, they are two distinct approaches to software development.

Ok, so XP isn't just another name or variation of Scrum. I get that XP is its own set of software development principles, but how does that impact my team's culture?

How does XP impact a team culture?

As already covered, there are four principles in EP - Simplicity, Communication, Feedback, and Courage. These are at the heart of what it means to have a Culture of Trust. A culture of trust begets a culture of inclusion. A culture of inclusion breads a culture of innovation. And a culture of innovation creates products and solutions that provide delightful user experiences. The pinnacle of engineering culture that we all strive for.

Let's break down these 4 principles.

#1 Simplicity

To be successful, software must be easy to use. This means that the code must be simple and easy to understand. The XP practice of "You ain't gonna need it" (YAGNI) helps ensure that code is kept as simple as possible. This also has the added benefit that your code and product become self-documenting, easy to change, and easy to refactor. This keeps your tech debt levels down and allows your engineers the time, space, and confidence to innovate. Empowered and happy engineers tend to stay put, which will help your employee retention rates, too (which is always nice).

#2 Communication

For a team to be successful, members must be able to communicate openly and honestly with each other. The XP practices of "pair programming" and "mob programming" help encourage communication by requiring two or more people to work together on every* task. Naturally, people who work together closely, talk to each other frequently, form naturally stronger bonds, and as a result, are more likely to step in and help each other out when needed. Your team, as a result, become loyal to each other and care about each other, which again keeps them happy and energised and helps your retention rate (there's a theme here?).

*A little caveat here is when I say "every", it's not a hard requirement. Sometimes there are small changes that have only a single correct solution and implementation, and in those cases, solo programming is fine. The general rule of thumb is that pairs and mobs are the norms, and solo work is the exception. The reverse of what you usually see, even in teams that claim to communicate and collaborate frequently.

#3 Feedback

For a team to be successful, members must be able to give and receive feedback. The practices of "pair" and "mob" programming that drove a culture of communication as a by-product drive this culture of feedback. Feedback becomes second nature and is baked into the development cycle, which, if you want, gives you a great footing to get rid of the often large bottleneck of the peer review process. The XP practice of "continuous integration" also helps ensure that feedback is given early and often by requiring every change to be integrated into the main codebase immediately. This allows people to test out changes quickly, iteratively, and with minimal changes required when problems are surfaced, and action is required. All of this practice and giving and receiving feedback also drives engineers to become better at their craft, and engineers who are improving are generally happy, which helps your retention rates (see where this theme is going?).

#4 Courage

Successful teams must have the courage to experiment and fail. The communication and feedback culture gives engineers a sense of psychological safety that allows them the courage to innovate and refactor tech debt. Refactoring helps encourage experimentation by allowing code to be changed without breaking the existing functionality, it helps to keep your code base clean and simple, and it ultimately allows the team the confidence to change direction, change technology, and otherwise do what they need to do to succeed without the fear of legacy code and tech debt. Engineers that can innovate and try new things and don't get weighed down by the heavy burden of legacy code are ... you guessed it, happy. Which (repeat after me) helps your retention rates.

By following the Extreme Programming practices of Simplicity, Communication, Feedback, and Courage, teams can build a Culture of Trust that will help them move fast and stay happy.

Ok, but how does this scale?

Extreme Programming was designed to be a lightweight process that can scale with a team. The practices are easy to follow and don't require a lot of overhead or additional processes to implement. As a result, Extreme Programming teams can easily add new members without worrying about process overhead, and the team can continue to move fast and stay happy. The added bonus is that this simplicity can apply to multiple teams and when added up, can function just as well for an organisation of 1 team and 5 people, or of 20 teams and 100's if not 1000s of people.

So there you have it; Extreme Programming is a great way to build a Culture of Trust that will help your team move fast and stay happy. And as we all know, happy teams are successful teams. And happy, successful teams don't churn, which keeps you happy too.

What do you think? Do you agree with the points made in this blog post? Let me know in the comments below! Thanks for reading! :) . . .

For me, this topic is highly relevant and personal right now. I and many others have been made redundant in the tech sector. Whether we want to call this "The Great Restructuring" or when "The Startup bubble burst" (Like when the "Dot Com Bubble" burst in 2000). One thing is certain, regardless of how talented you are, how skilled you are, and how much everyone talks about a skills shortage in our industry, getting made redundant sucks. You're left feeling deflated, uncertain, angry, and worried about your future. At this point, to rub salt in the wounds, you're now competing against the thousands of other talented people in the same situation. It's hard.

But this isn't the first time I have faced this down. It probably won't be the last (I'm a perennial risk taker addicted to early-stage startups and scale-ups). So here is my guide on how I survive and thrive post redundancy.

#1 Check your Agency!

No, not that kind. I'm talking about your power to control your life, make decisions and enact change. This is what Personal Agency is;

"Personal agency is the belief that we are in control of our lives and our destiny. It's the ability to direct our actions, thoughts, and feelings and to be responsible for the consequences of our choices and behaviours."

In other words, it's taking control of your life and owning the decisions you make. Now you know what it is, let's see how you evaluate it.

The 5 components of personal agency

Agency comprises 5 things; Opportunity, Awareness, Skill, Resource, and Intent. Your ability to influence the outcome relies on having everything in your control. A lack of, or misrepresentation of, one of those 5 components will drastically impact your agency in any given situation. Let's dig into each one a little bit.

Opportunity – This represents whether circumstances allow you to act, i.e., whether you have the chance to do something. A doctor must have access to a patient to treat them. In context, their agency is limited by their physical proximity.

Awareness – This is your conscious recognition of the opportunity to act, i.e., knowing there’s something to do. Without a way to know that someone is unwell, a doctor will not be able to treat them.

Skill – This represents your relevant physical and mental abilities, i.e., what you can do. A doctor has been trained to diagnose and treat illness and injury. Without that knowledge and skill, they would be ineffective in their attempt to help and would have limited agency in the situation.

Resource – This represents the things, tools, and information you need to act, i.e., the stuff needed to do what can be done. Without the proper equipment and medicine, a doctor can do little to help a patient and have limited agency.

Intent – This represents the choice to act and the understanding of the effect, i.e., that you mean to do something to create a specific result. If doctors do not choose their actions or recognise the effect, they can only achieve a limited outcome. The conscious purpose is a critical part of your agency.

How to use your agency to help you now

Now you know what agency is and what it consists of. "Great; how does that help me?" I hear you ask. Let me tell you.

Use Agency to let go

Evaluate your current situation, evaluate your agency in that situation, and let go of the thoughts and feelings where you had little to no agency. Nothing you could have done would have avoided this situation. So let's use the agency we have to do something proactive instead.

Use Agency to give yourself a confidence boost

Let's start by using it to give yourself a confidence boost and to help get you over the post redundancy blues. Look for small things you can do, professional or otherwise, where you have complete control of your agency. For me, this was landscaping my garden. I was in control, had all the agency aspects I needed, and could take on the project and see it through. Having something to do, a goal to reach, and achieving that goal gave me a great sense of personal pride and fulfilment. Afterwards, I was already feeling much more positive and confident. And confidence helps in interview settings.

Use Agency to move the needle

Use your agency to engage your network, and move the needle forward without getting weighed down by the things you can't control. How else can you utilise your agency? You might not have control over the outcomes achieved by this, but you can certainly set yourself a goal of proactive outreach that you have complete control over. Aim to reach out to a set number of former colleagues or people of influence in your professional network each day or week. Begin to upskill yourself; if you have the agency, find a new skill you want to acquire, be that a new programming language, framework, or methodology, and get it. Watch courses, write code, whatever it takes; if you have the agency execute on it, do it. I'm sure there are many more ways than the two listed above, but you should look for ways to improve your chances of finding and securing a new role that you have the agency to see through and execute on them.

You've taken care of yourself; now look beyond your agency!

You've let go, taking care of everything you have the power to do, and now it's time to look beyond yourself. Having a strong sense of personal agency and self-reliance doesn't mean you can't or shouldn't ask for help. Look at some of the outcomes you seek, where you are lacking in an area of the agency, and use the agency you have to find people who can fill that gap and give you what you need to succeed.

#2 Research and evaluate

The next tip is to research and evaluate your skill set. Think about your skills, what skills you can demonstrate well, and how you have utilised them in your last (and other recent) role(s). Now compare your skills against job postings online. How do you stack up compared to demand? Is your skill set in demand? Are you missing an essential skill? Once you have determined where in the current market you sit, you need to work out your worth.

Your worth is irrespective of your current salary. Your current salary could have been way over the market. It could be way under market. It could be the current going rate. The main point is that the market has probably shifted since you last secured a role or negotiated a salary. Don't treat your past knowledge, research, and experience as a barometer for now. That would be like dressing for tomorrow based on last week's weather. Always assess the here and now. That is the market you're working in.

The best places to start are by looking on job boards, hitting up google to search for salary benchmarking and speaking with recruitment companies. Between those three points, you should be able to get a fair sense of the current market value for your skill set. Now comes the big question. Does the market value pay more, less or the same as your last role? If it pays more, good for you; get that pay rise. If it pays the same, that's great. You're playing in the right ballpark. The tricky part only comes if it pays less. Now, what do you do?

You need to evaluate yourself and your situation. Do you provide additional skills and qualities that are quantifiably worth more to a company? Saying "but I'm a far better at X than the average" isn't going to cut it; that's going to be objective. Do you have management experience? Team Lead experience? Have you got a track record of delivering above and beyond results within budgets and timeframes? Can you prove this? There are many things to assess, but you need to work out if you can justify asking above the market.

So you have decided you can justify it ... ok, great. Now you need to do two things: re-evaluate the job market and see how many roles are out there paying above the market. And you need to look at roles that are a step up from what you were doing and see if they pay the rate you're after.

You should now have an idea of what space you're playing in. How many jobs there are that meet your expectations. And if you're going to need to stretch yourself and apply to roles above your last one by demonstrating that extra value adds you bring above your current role.

You have one last thing to do before you start throwing out your CV. Look at your finances and your lifestyle. After all, this is a volatile market with strong competition. You need to prepare for the worst case. What spending could you cut back on? What are your mandatory expenses to keep yourself (and your family) going? How does that number compare to your desired one, and how does your desired number compare to the market? Is there a big difference, a slight difference? I can't answer this one for you, but as a rule of thumb, if there is a big difference, focus more on the role than the money because you're sitting pretty; you have many options available because the market is paying more than you need. If the gap is big, and the market is paying less than you want but more than you need, prepare to adjust and include this adjustment "cut-off" in your plan. It only gets tricky when the gap is small, and you are asking for more than the market. In this situation, you need to start evaluating all your options, I'm not a financial advisor, so I can't tell you how to handle this scenario, but my advice would be to speak to a professional to see what they advise and what your options might be.

Let's move on. Set your boundaries, and make a plan.

#3 Set boundaries and have a plan

The first part is easy. Set your boundaries. You should already know the absolute minimum comp you need and your desired base comp. The next thing, what are your other non-negotiables? Do you categorically require fully remote, or could you be flexible and do 1-2 days in an office? Think about all of the "perks" and benefits on offer. Which ones have you utilised? Which ones sound great, but you've never really used them? These are the things that build up your boundaries. For example, you might come to this kind of list;

Upper Bound (The realistic ideal):

• £150K Base
• Unlimited PTO
• Private Health Care
• >5% Pension
• Staff Engineer Title
• Start-up/Scale-up

Lower Bound (The lowest acceptable situation):

• £110K Base
• 25 Days Holiday (This is how many you usually take on average)
• 5% Pension
• Senior Engineer Title

You can see that your base is much lower in the lower bound. The title might be what you have now rather than what you want. The pension is based on your actual average contributions right now. The PTO is based on the average you take in reality. You live in the UK, so you've dropped the private health care as you've never claimed on it before (Thank you, NHS). And although you love the world of start-ups and scale-ups, you could live with being in a larger corporate setting for a while.

So now you know what you're aiming for and what you'd accept. You've now got a sliding scale to work with when assessing roles, speaking to companies, and deciding if to accept an offer. My advice in this scenario is that you should accept anything that meets or exceeds your lower bound. You can always keep an eye on the market. You can always move on. The most important thing right now is your well-being and the well-being of your family.

Your scenario may be different. You might have a nest egg to last 6 months, in which case, you can be as picky as you want; I can't answer that for you. But through my experience, it's better to secure a role and move on 6 months later than to take a risk and burn your savings. Keep your savings for what is important, the future of your family.

#4 Be resilient

This last point is the most difficult, and you might need to keep reviewing tip #1 and assessing your agency, but you need to be resilient. It's going to be difficult. You will likely receive rejections, sometimes after interviews, sometimes in a very impersonal email sent from an ATS (Applicant Tracking System). Now it's always effortless to say "stay positive" or "be resilient", but it's a lot harder to do in the face of adversity and rejection. This is where I like to "borrow" some of the tenants from Stoicism (the philosophical school of thought). One of the things they advise you to do is to think about and reflect upon worst-case scenarios, this isn't to say to wallow in them, but it's simply to visualise them, imagine the feelings, and let yourself feel them for a moment, then move on. In stoicism, this practice is supposed to help you "prepare" for that scenario by allowing you time to feel and process this outcome before it ever happens, in theory lessening the load if it does happen. The other intent is so that it causes you to appreciate what you have now and to enjoy what you have now. That second part isn't very relevant in this situation, but I find the visualisation technique helpful in receiving rejections.

My other tip for resiliency is to look for and ask for feedback, you may often not receive any, and for that, I developed another "hack" that sometimes works for me. At the end of an interview, when asked if I have any questions, my final one is always something along these lines. "Is there any understanding, skill, or aspect of my career experience that you wanted to hear more about or that I haven't given a satisfactory answer to that will leave you unsure about my capability or suitability for the role so that I can attempt to address that concern now?" Sometimes the answer is no, sometimes you get good feedback, but it always gives me a pulse check on how it went when you see or hear their reaction to the question.

Overall, building resilience in this situation is about being prepared for rejection, looking for feedback to allow you to address areas of weakness (or perceived weakness), and trying to learn from each interview the same way you learn from each iteration in a development cycle.

As a reminder, this is the exact situation I am in now whilst writing this article. I'm 2 months into redundancy, on the precipice of surviving on my savings whilst trying to support a young family. So this is how I tackle my feelings, staying positive, being resilient and keeping my foot on the job hunt gas. I hope it helps you too.

Keep your heads up, keep going, and reach out to talk to me if you need someone to listen. I'll see you on the other side!