Posts tagged with "#management"

Note: This was written in August 2022 and I assume things will change quickly. It will be interesting to look back in a couple of years to see how much of this article is still relevant!

Most tech organisations were forced to change to remote during lockdown but haven’t explicitly changed their office attendance policy.

I’m writing this at the start of 2022 and it’s never been tougher to hire engineers. There is a very strong candidate market in software engineering at the moment.

There are roughly 1 million open software engineering roles in the USA and somewhere around 200,000 candidates. The rest of the world is having similar issues hiring engineers. Most people seem to think it will be this way for quite some time. There just aren’t enough engineers as software becomes more important to every industry.

When I started my career getting hired was skewed in favour of the hiring organisation. A candidate had to have a degree and there was no remote work so your choices for where to work were limited.

Now, in 2022 candidates with a couple of years of experience are in high demand and practises for hiring have changed significantly. You can work anywhere across a few time zones and university degrees thankfully aren’t necessary any more.

I’m mostly on the other side of interviews these days, so my are tips for other folks trying to hire engineers during these tricky times!

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.

Your most impactful engineering is done before you write any code.

It’s important to have some systems around how you approach problems to make sure you’re consistent every time.

These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.

No one wants to waste time working for an organisation that’s a bad fit. But how do you know a good place from a bad place until you actually work there?

It’s important to spend the same amount of time analysing a potential organisation as they spend analysing you!

During an interview process an organisation has personality testing, resumes, tech testing, behavioural testing, reference checks, bank checks, police checks and more.

If it sounds like a very one-sided process that’s because it is! But there are ways you can bring more balance and here are some important things to research before accepting any engineering job offer.

Engineers spend most of their learning time on technical implementation content. Things like new frameworks, languages or cloud platforms.

But turning solutions into code is a tiny part of what you do and it’s getting less valuable year by year.

As we’ve seen with “no-code” and tools like GitHub Copilot, the implementation part of our role is increasingly becoming commoditised.

You could generalise that the value an engineer brings to a team is their ability to analyse problems and synthesise context. The part of your role as an engineer that will never be replaced by “no-code” or AI is this high level cognition.

The true human aspect of being an engineer is working in a team and considering other people’s ideas, emotions and thoughts while solving these problems.

So shouldn’t you train these meta-cognition skills as much as you train the specific technologies?

Every engineer should spend time learning and applying general tools for thinking. These tools are applicable to almost all problems so the compounded payback on your invested time is huge.

Clearer thinking will amplify all the other skills you have and any frameworks or tools you learn will give you results for the rest of your career.

Like any skill, improving the way you think takes deliberate study and practice.

These are some of the tools and systems for thinking that I refer back to all the time.

Have you ever struggled to explain the business value of a piece of engineering? Like why a particular piece of tech debt needs to be paid down now?

Engineers can learn from the techniques and rigour that product management practice has created in the past few years to

1. To show business value in their own engineering work where it’s not easy to articulate
2. To empathise better with customers of the software their building
3. To understand the business context you’re in

For example, how can you know that you’re building something useful for your customer? How can you convince others that you’re not ahead of your time with an engineering solution?

For engineers there are some product development lessons that will improve your empathy and communication with non-engineers in your org.

I recently had to estimate 6 months of work for a new product after just 2 hours of discovery. This is a short deadline for an accurate estimate and I felt uncomfortable providing a number.

I ultimately gave a gut feeling estimate for the work because that’s my job and we needed one by the next day. I did specify it was at least 20-30% wrong and highlighted the major risk I saw - a new third party integration that we had never integrated with before.

The whole scenario got me thinking about what works and doesn’t work for me when estimating larger pieces of work. Here are some of the thoughts, tips, tricks and learnings from 10 years of providing dodgy software estimates!

Just like modern product development, the best practices for your team also come from learning, iterating and adapting to changing requirements. There are no “best practices” that can be applied to all teams and the way you work will likely be unique to your team’s requirements and outcomes.

Applying a software tool like Jira or GitHub PRs locks a team in to the tool’s practices. The team’s practices become tightly coupled to the tool’s prescription.

The danger here is that the tool accidentally becomes “the way we do it here”. The original reasons the tool was chosen are forgotten and it’s more difficult to experiment with better practices when your team is artificially bounded by a mandatory tool.

Building a new product likely means you’re building as quickly and as scrappily as possible to get to market. For a web app this is usually a short push of 2-4 months and If you’re successful you now have a product that needs to transition to a more sustainable style of development.

Here are some of the things I’ve observed or implemented to make this transition deliberately. Hopefully there are some things here you can use to prepare yourself for transitioning your next successful project!

Many organizations use an anonymous feedback mechanism to get feedback from their employees.

However, if you only emphasize an anonymous feedback mechanism or your team is asking for an anonymous feedback mechanism take it as a HUGE red flag around trust.

The people don’t have any safety to talk about their issues with the organization or colleagues in a transparent way. You should do everything you can to provide trust and safety for transparent feedback.

The “Spotify model” is an incredibly popular organizational methodology for managing work across teams. Personally it’s been present in some form in the last 4 places I’ve worked since 2014.

The Spotify model is a matrix organisational model that highly values team autonomy with servant leadership.

Now the critical thing is that you have to enable the team to be autonomous! You need to support the team members at their various levels of experience on how to be autonomous and effective. If you do this you will also get higher engagement in your culture and the actual work.

At the end of a project or when a person is leaving a team or project, it’s nice to show the impact that they had on the software visually. Git has some built in statistics that will show you tables listing additions and deletions, commit counts and that kind of thing. But you can use gource to create a cool time series visualisation showing the changes over time.

It’s well worth checking out this tool.

When you’re reviewing RFP (Request for proposal) responses you make sure that the provider has met all your specified requirements. A provider missing a requirement on the proposal is a bad signal. Then you weigh the response details against each other and finally the price gets calculated and you choose.

But here are 10 specific signals outside of the standard stuff above that I look for.

According to research by Professor Steven Rogelberg 50% of meetings are seen as engaging - of course this means that 50% are not.

From my own experience I would have to agree that many meetings are not very useful. There are too many organisations having meetings that would be better as an email or a wiki document.

I was asked for some advice recently - “Should I apply for this open team lead role if I am not technical?”

In this case I found out that “technical” meant “is a software engineer”.

If you’re employed in a software product development organisation already then the short answer is yes, you absolutely should.

I’m a lazy team lead. I like to ‘free up’ as much time as possible at work. I run away from ‘busy work’ like it’s on fire. Here are four rules of thumb I use to decrease the amount of time I spend doing some management stuff so I have time to think and work on more valuable things.

There’s always more work to do than time available to do it. Effective prioritisation is very important to provide the focus to be successful at work.

In general prioritisation is some product of effort x cost x time or value x complexity applied to possible tasks. The tasks should be aligned to your strategy.

There are some well known frameworks for prioritisation that I find useful. I’ll describe them here and talk about how to choose one with your team.

Is testing “slow” in your team? Do tickets pile up in the “ready to test” column every sprint?

If you think that the testers on your team need to fix this you’re wrong!

In a cross-functional product development team balancing the cadence and handover between development and testing is often a pain point. Read on as to why this is team problem and it’s best resolved by getting developers to thoroughly test their own work.

Late last year I had the pleasure of helping a team of students build a prototype for a non-profit here in Auckland. The non-profit needed a prototype to raise more funds and get feedback on their plan.

I’ve helped run teams and mentor junior developers in large organisations. It’s much easier because the support, tools, frameworks, systems of the organisation are already available. For this project the student teams had a blank slate and had to decide on everything from how they would communicate with the sponsors to how they would host the software.

I wanted to write down what I learned and note some of the mistakes I made so that I have a framework for the next time I help new developers!

I lead a team of developers that work on one of the busiest New Zealand websites. We have ~4 million members and ~850,000 unique users every day. Working at this kind of scale means the real people who buy and use our products can get lost behind user personas or Jira ticket numbers.

If you’re selling your teams on some form of agile but the reality they work in is completely different, you are damaging and demotivating your teams through confusion and an impossible to achieve vision. If you’ve adopted ‘agile’ do yourself a favour and check the health of the adoption right now.

A.k.a. how to get the truth from your direct reports while you sit back and eat cake.

You’ve been a manager for a year and you’re not sure it’s all going OK? You don’t know if you’re providing maximum value to your team or which specific aspects of your people leadership to improve?

Last week I offered to give a workshop on machine learning to share some of what I’ve learned so far. I had 2 goals for my workshop – first, I wanted to show everyone that they shouldn’t be afraid of machine learning. Second, I wanted to get people set up with anaconda so they can continue to learn themselves.

Last week I had an amazing opportunity to present about machine learning and innovation to 110 people leaders at my company. It was a mixed audience of technical and non technical people.