“Employees aren’t just cogs in a machine” — Neil Mountford reviews his first months as a new VP of Engineering

The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

You need more friends at work

The public doesn’t seem to appreciate hustle culture anymore.

While boards of technology companies still name operational efficiency as their priority goal (2023, Nash Squared), there’s a visible shift towards employee (and customer) care.

Executives can’t risk getting canceled by comments on Glassdoor, on Linkedin, or by The Verge because of their dictatorial leadership style.

While we connected with Neil to review his first months at Habito, the conversation shifted to inspiring coworkers to support change through proper management.

If you plan to enter management — or are just curious about what you could do better to find allies at the office, Neil will explain:

• how to earn the approval of your new engineering department,
• what changes he introduced to make IT efficient without causing a riot,
• how servant leadership empowers employees to excel.

About Neil & Habito

Onboarding and first priorities

Eric Ignasik: Hi, Neil. It’s good to meet you! You’ve been at Habito for 8 months now. After your first month, what did you like about how the engineering department worked, and what did you want to improve?

The first thing I noticed after I joined was how helpful the whole engineering department was. I’ve worked at places before where engineering wasn’t that well liked. 

People often say no, or “it’s not possible”, when you’ve got a big business, and everyone requests a change, but the IT department is too small. 

But actually, at Habito, the ad hoc requests were often small enough that the engineering department could service them. So they’re very well regarded. They cared about the customer experience a lot as well.

I also saw engineers would push back at the right time and make suggestions about how a feature could be better for the customer, which is really lovely. 

It wasn’t just about the technical side of it. IT often asked: “How does this work?” or “Is it a good experience for the user?”. 

Servicing small ad hoc requests is a double-edged sword though, as it takes the focus away from the core business projects. 

Way before I joined Habito, the company experienced tumultuous times. When Ying Tan took over as CEO in 2023, he finally got it back on track.

My first goal was to change how work came to the engineering department. 

Michael Sols: What were these ad hoc requests, and how are they processed now?

There were a few big data retention requests about deleting or cleaning up old records. Because Habito is regulated, it needs to be up to date. 

We also used to get a number of requests for changes that could be made using our CMS.

Luckily, we automated the data cleanup and produced training materials around our CMS, reducing the ad hoc requests a great deal.

So, automation got rid of a lot of those requests.

Habito’s IT also shared a lot of manual updates, which required a weekly update in one Slack channel, plus ad-hoc updates in other channels and private messages. Various business people asked about the project’s progress.

Because of this, I re-introduced a sprint board for the department. The engineers used one for tech tasks, but there wasn’t a full project backlog with well-defined tasks.

There also wasn’t a sprint board for project work, bug fixes, or for these ad hoc requests.

Now that a board has been introduced as the source of truth, all project stakeholders can just look at it to see the completion rate and the tasks in the pipeline.

We’re still improving our workflow. In these past months, we’ve tried a few new tools.

Before I joined, I used to work in JIRA or ADO. At Habito, we cut down the number of software-as-a-service tools we rely on. Now, we’re trying to adopt Notion boards, which we are quite tentative about as this is still a new tool for everybody.

Interesting. This is the second time we hear technology leaders adopt Notion.

After you joined, who did you connect to, and what did you ask for to understand Habito’s business and the product?

Before Habito, I worked with Ying Tan, the new CEO. Actually, I was asked to do technical due diligence when he was looking to invest.

After doing the analysis, I already had a good understanding of the product and the stack used.

In my first weeks at the company, I talked to other executives to learn about their responsibilities, problems, and the day-to-day work they and their departments did.

Putting that time in gives you a much better idea of how everything within the business fits together, which then helps you focus and prioritize better.

If you have 30 people in a department who all have the same problem, that adds up quite a lot and should go straight to the backlog when compared to a problem that only affects two employees.

Obviously, I also spent a lot of time with the engineering department, diving deeper into the tech stack to understand how the product was made.

What surprised me was that they used Haskell on the backend, which I’d never encountered before in production.

Michael Sols: Did you rely on Habito’s documentation or decided to outline processes yourself based on these conversations?

If there had been existing documentation, that would have been good. Habito went through many rapid changes before my time there, so, unfortunately, the information was very out of date.

That’s why I went directly to people and made my notes.

I have my own public space in Notion anybody can look into. I believe in openness and collaboration.

Eric Ignasik: IBM’s study says that the most common type of CTO spends over 80% of time advising the Board.

Using percentages, could you explain which areas you focused the most on in your first months?

Sure. I’d say I spent around 30% of my time to understand the business, its departments, our customers, and individual and shared responsibilities.

The next 20% I put into getting to know the individuals who make up the engineering departments, asking myself: “What makes them tick?”; “What do they want to achieve with their career?”; “What concerns do they have?”.

After the turbulent period, the company went through, I really wanted to meet and greet everyone in the department, offer my personal support, and try to get the morale up.

Interestingly, something like 25% of my time went into coding a platform that Habito acquired. I am still a bit hands-on with the product.

Still, it’s nice to have visibility into day-to-day development to understand Habito’s engineers’ pain. It makes me want to solve problems for them.

And then, the 25% left I spend improving internal processes, streamlining work, and giving employees visibility into our workload.

That’s what made me ask:” Why are we getting ad hoc requests? Can we stop or push them back temporarily?”.

Eric Ignasik: You spending 20% of the time to code is respectable. Nowadays, a lot of technology managers are expected to be hands-off.

Yes. I think it depends on the company size. You can’t be hands-on when you have 50-100 engineers. 

But at Habito, we just have two engineering teams, so I’d like to be involved in development as long as possible.

Everyone probably had a point in their career where they worked under a technology leader without development experience.

Engineers respect managers who understand what the conversation is about from direct experience.

Still, I believe my time coding will have to decrease. Habito reached its first month of profit in September 2023, and now, we hope to start growing departments again. 

I’ll have more people to keep happy in engineering and new work to prioritize.

How to earn a good reputation

Could you explain the hardest challenges a new VP of Engineering could face?

Joining an existing team is the toughest.

If you’re building an engineering department for a startup, everyone can get quite closely knitted.

Coming in as an outsider, you need to earn that respect and introduce change without upsetting the in-house team. That’s especially true if they worked through layoffs, for instance, and their morale weakened.

Your idea as a new leader might be to rebuild the processes engineers are used to.

But you’ve got to find the empathy to understand they could have experienced a wave of change recently.

I didn’t want to rock the boat too hard and make people lose their sense of stability.

I want engineers to take part in leadership decisions for them to feel empowered by me. 

One way I did that was to embed myself into the team as a servant leader and ask what they needed to carry on.

So, I’m hearing that the human link is the challenge rather than a messy code base or out-of-date documentation.

Yes. You need to make people happy about working with you. It’s much easier to patch up a code base than to fix broken relationships.

I know you went through changes in engineering. But which technologies or processes have you implemented for other departments to make work easier?

I needed to give engineers some breathing space away from the pressure of competing priorities from business.

We had a lot of maintenance work that was a burden. We ran a Kubernetes cluster, had loads of stuff in AWS — all as microservices — and there used to be more DevOps handling all of that.

I tried to focus the business on the highest priorities so that engineering could balance the workload better.

I’ve also been encouraging engineers to simplify their technology choices a bit.

At the beginning of my tenure, most of the services were in Haskell, but there were some less-used Typescript ones, which I pushed us to clean up.

We now have the backend in one language. We had a mix of PureScript and TypeScript on the front end as well, and we are in the process of consolidating it with just TypeScript.

When Habito grows again, onboarding time for one person will be much faster.

If you have to hire someone to work with eight or nine technologies, that takes so much time, and it doesn’t have to.

Yeah, that makes sense. And how do you train, motivate, and inspire engineers from whom you expect better performance?

You always need someone’s buy-in regardless of their performance.

If you dictate what engineers need to put in place or to anyone else, it just doesn’t work. People aren’t mindless zombies. They need to have agency.

I always try and follow the servant leader approach and use discussions to determine which knowledge areas an employee needs training in, why, how it benefits them, and what the business gets from it.

Questions like that help us find an individual training plan or learn that a certain engineer prefers different projects from what they have.

I’ll then try to cater to their preferences and find fitting assignments.

It can be challenging because what a person requires must also be balanced with the business’s needs. At the end of the day, we’re all trying to make the business a success.

Once I figure out a personal growth plan with an engineer, then we can discuss their performance. You’ve got to be honest.

If my teammate could do better, they need to hear how specifically they’re falling short at a one-to-one. I want them to know what they need to improve. Then, we come up with a plan together.

Again, it needs to be collaborative because the learning process should be a positive experience. So you can say: “Okay. What goals do you have? How can we get there?”.

Be a teacher rather than a manager

Could you explain the servant leader management style from your perspective so that our readers can compare it?

A servant leader will work directly with engineers and explain how their work impacts the business.

I could say: “This will drive this amount of revenue,” or “It will get us 20% more customers, so more money will come in, which is good for us.”.

We want engineers to see they’re an important part of the business, which will hopefully motivate them to help it succeed.

For me, explaining “why” is key for a servant leader. People forget that. Employees aren’t just cogs in a machine. You need to help them understand and motivate them.

The other side of servant leadership is to help the team understand how we get there.

I have this new feature that needs to be delivered. What do we need? How long will it take? What are the blockers we’ll most likely see?

A servant leader should drive a discussion and not control it.

So I shouldn’t say: “Oh, you know, we need this in a week., when engineers state two and a half weeks are required. 

But if that time is too long for me, I still have a chance to ask if we could consider cutting out features.

If we can limit the scope, that’s great. If not, we’ll go ahead with the engineer’s estimate without rushing people. Rushing them only results in poor-quality work and reduces team motivation.

In my case, the point of servant leadership is to give engineers agency and control over their destinies. I’m just there to guide them and make sure they understand the reasoning behind the business decisions.

Michael Sols: Neil, it’s another time we hear about servant leadership in the series. Ben Brow — another gentleman from the UK — really emphasized this idea.

Is there even a different management philosophy that would work for engineering?

I’ve worked at places where the approach to IT is more dictatorial. 

At many companies, leadership says: “This needs to be done. Here’s a hard deadline.”. 

It never works because you can’t just come up with an arbitrary deadline for development work, as it actually demotivates people.

Directors telling engineers what to do when there’s no option to discuss how long it takes is like me calling in a builder to build a skyscraper in a week.

People are going to be miserable, and I won’t be happy with the results.

It’s a lose-lose situation.

I genuinely think the servant leader approach is the only one I’d consider, although other technology leaders could disagree with me.

Eric Ignasik: What do your peers and colleagues at Habito expect from you?

So, I think the engineering department expects me to shield them from ad hocs. It’s very easy for the management to get into the habit of expecting all sorts of things from them.

And I think they also expect me to keep their work focused on one or two business goals. 

Context switching is always a big time sink. We’d like to avoid having four requests at the same time with one person per request, as nothing gets done this way.

Leadership expects I’ll keep them up to date on progress or blockers that could affect the delivery date.

The board also wants me to explain technicalities in an approachable way. They don’t want to hear how a DNS record in the cluster is misconfigured.

For them, it’s also my responsibility to think about the longer-term technical strategy we should consider. And to make sure expectations are realistic.

Right now, AI is a great example of that. The technology has created a lot of opportunities, but many businesses sell it as snake oil.

It’s very easy for someone to get excited about AI if they’re unfamiliar with what it can actually do.

So, leadership’s expectations for AI are way up here, but what it can do is down there.

My role is to cut through the noise and figure out if it can really be a part of our strategy.

Michael Sols: I’m wondering if you’ve already heard some vague idea of adding AI as a feature to Habito’s product.

Overall, I see a big push to use generative responses for first-line communication.

While AI improved a lot, at Habito, we pride ourselves on connecting customers with real people.

When you fill in some data on Habito’s website or use the chat, there are no bots whatsoever because choosing a mortgage is a big life event, and we treat it with the attention and respect it deserves.

Some business people might say, “Oh, but why don’t you use AI? Just put it into the product?”. But we are not there yet.

We don’t want our customers to interact with AI instead of us. But there are other areas where using it is exciting.

We are using Github Copilot. It gives us 5-10% productivity gains. The engineers like to use it to write boilerplate code.

So that’s a good use of AI as we can actually measure the difference it makes and the sentiment it creates.

Do you have a specific communication strategy to turn down requests or negotiate the middle ground?

Yes. I tend to take a one-to-one approach. I don’t want to call out people in a public Slack channel or on a team call.

If dozens of ad hoc requests come from one person, I’ll speak with them.

I think being empathetic matters. Why are they asking for it? Does it save time for their department?

You often find that such requests aren’t that important. But because engineering previously delivered something that person asked for, they continue to get assignments since the first one didn’t seem like a big deal.

Once I question the importance of a request, I could hear it can wait a month or two. IT can use this time to come up with an automated self-service solution, for instance.

In a case where engineering could write a script to save hours for a department, then I’ll probably speak to other executives to raise a request as a potential work stream we should introduce.

Good to remember

Eric Ignasik: What are your 3 rules for other Technology Managers who have just entered a new organization?

I wouldn’t call them rules but rather advice. My first tip is to understand the business, processes, and people before making changes.

Nobody likes it when an outsider comes in and flips the table without understanding the space first.

Then, I think you have to foster a collaborative and empowered team. People work best when they’re not treated like a cog in a machine. Allow them to make some decisions as well.

I also have a small bit of advice — communication is a two-way street.

I like to attend daily stand-ups and give an update to the team. It might not be as interesting for them as I don’t deal with pull requests or code problems.

Still, me taking part in daily stand ups and being open about what I’m working on fosters that collaborative attitude.

Resources

Could you recommend books, podcasts, or courses that taught most about being a respected leader?

There are a couple of books I’m a big fan of. “The Phoenix Project” by Gene Kim is one of them.

I really like the way it’s written because It’s a novel rather than a textbook. It’s a cool way of explaining how to improve business processes.

And the book has a couple of characters that might remind you of someone you worked with.

“Turn The Ship Around!” by David Marquette is another good one.

He was a US Navy captain who took over this submarine that had the worst morale — like an office can.

Everyone was just getting reassigned. I wouldn’t like to serve there. David found the crew was just following orders even if they were impossible, which disempowered them from making decisions.

So, he fostered this space where he’d encourage everyone to be a leader in their own right. People regained the power to make decisions.

He made the submarine one of the most efficient in the fleet.

Although the book doesn’t deal with technology, it’s important to look outside our own bubble sometimes.

I don’t have any courses to recommend, but I have leaders I respect, and I try to emulate their behavior. That’s what I’d recommend.

What’s next? Three actions for CTOs to take

What usually happens when a new manager joins?

They experience an “Oh shoot” moment once their new team reveals all the challenges that wait to be solved.

And then, it’s easy to be bossy when expectations pile up.

But Neil and some other interviewees seem to have told themselves: “I’ll be a better manager than those I came across.”.

They found another way. For the newcomers, Neil recommends:

1. Review ASAPs that come to engineering and let it focus on core projects through collaboration — not orders
2. Go to each department directly to understand their needs and problems without relying on reported information
3. Explain the “why” behind what  IT needs to do, and keep proving how their work lets the business grow

Learning to serve rather than manage doesn’t mean work results get worse. We hope that’s what you’ll discover in a new role one day.