Shifting Your Culture In 3 Steps

As a leader I often need to make changes to mentalities with are deeply engrained in our company culture. I have a simple three-step process for this:

1. Team Discussion

The first step is to raise awareness of the issue with your team. Make sure to explain what the issue is and why it is a problem. Allow the team to share their thoughts and build a solution together. You need to be open and listen during this conversation, it is not an opportunity for you to sell your solution to the team (which is most likely based on preconconceived ideas, and furthermore won’t get buy-in if it’s forced on the team).

Case Study (pt 1): We are an agency who bill work by the hour, however we were not logging enough billable hours. I shared the problem with my team and why it was a problem (less money for the company, less money for individuals via profit sharing). Then I listened as the team shared issues and we discussed and problem-solved together. Finally we agreed on a way forward: we would all take personal responsibility for meeting the billable hour expectations and we would communicate any issues as they came up.

2. Individual Discussions

I’ll use our next weekly 121 session to bring up the issue. Do they understand what is required and why? Do they have any concerns, questions or suggestions? This gives people a chance to share things they may not be comfortable with in front of a group, or gives us a chance to dig into items which are individual to them. Additionally they will have had a cooling off period of up to a week to think through the topic and come back with further ideas.

3. Accountability Loop

Steps 1 and 2 lay the groundwork, but most likely the idea will slip if there’s no follow-up. You need to come up with a way to keep people on track. Some sort of report or dashboard can help, depending on the case, but you need to make sure you’re looking at it (I’ve made the mistake of building and forgetting dashes more than once…). Follow-up with people who aren’t getting it done to ask why. Make sure you come from an inquisitive standpoint and not accusatory, there are likely blockers to be addressed that no one considered yet.

Case Study (pt 2): I started to review the time tracking reports every Monday. I publicly congratulate those who hit the target, and ask what support is needed by those who didn’t.

The final thing to remember is that your cultural changes are never “done”. Keep discussing them in your team meetings, 121s, retrospectives, etc and iterate as you go. Have fun and let me know how it goes.

WFH With Kids

This pandemic has created many challenges for us all, but has also provided many opportunities to see life from a different angle. Some of the challenges have been especially great for those of us with kids (I have two boys, aged 5 and 2). I discussed this with other the other parents in my team…

What challenges have you faced?

Explaining to two little kids that I have to work is hard because they see me in the house and want to play with me or show me stuff, they don’t understand that even though I’m home I need to work and can’t be with them. It makes it harder to concentrate on my work and ignore my kids while they talk to me because I feel bad for that; also, staying at home makes me feel that I should help more my wife taking care of the kids so she’s not carrying all the charge of them.

Manuel Padilla, Engineer

For us parents, balancing between work and parenting has become even more tricky whilst working from home. Like Manuel, all of us also find it hard to strike a balance between spending time with the kids ands getting some work done. And we worry about how our kids will feel if we “ignore” them.

It helps me to close the door whilst I’m in meetings, but be flexible with my attention if I can be. I also start work very early and finish around 4pm, which allows me to spend time with the kids in the afternoon.

What about the upside?

I can do much more and feel comfortable in all my roles: as a woman, professional, mother and wife. Not spending too much time commuting, I can exercise, have time for myself, spend quality time with my family, play with and educate my son, spend time with my husband, cook, do all the house chores with the help of my husband when his boss let him work from home (we work as a team) and still be able to work full time.

Ilham Moutaharik, Engineer

Time saved from commuting has helped us all connect more with our families. In addition, being home to have lunch as a family has been a huge gain for me and many others. In general, I feel the pandemic has connected me more with Ellie and the kids, we have become a stronger family for it.

Another benefit that Priscila recognised is that we are all now more aware of what we do, our partners and kids can see what we do at work, and we can see what the kids are learning at school (unbelievably, schools in Mexico have been closed for in-person lessons for nearly one year now!!).

What have we learnt?

When you work at home with your children, the ability to fully concentrate becomes a challenge and I think that is where I have developed the most, being able to prioritize my attention and really focus on something no matter what is happening at home. It is difficult to ignore things that happen around you and you feel the need to intervene but you have to learn to keep your attention on what is important at that moment.

Daniel Urruela, Lead Designer

Planning our days around our family has really helped, many of us now start work much earlier and set expectations with our families on when we are available for them. Having a room with a door is also really important!

I’ve learnt the importance of family, our connection with our partners and children is so important and should never be prioritised below our work.

Summing Up

I have learned that change is the only constant and that we need to be more adaptable. I have also learned to be respectful with my working times and our spaces. And I think both of us have learned a lot from each other through spending more time together. 

Priscila Hernandez, Chief Strategy Officer

Priscila hit the nail on the head again, change is the constant. If we stay optimistic and adaptable then things will work out.

What’s one thing you can change right now to improve your work-life balance?


When I started out leading a team, I didn’t consider that I needed to empower my team to grow. I just figured they would grow naturally, but I was wrong. It’s not that they lacked guidance, but more that the culture didn’t encourage everyone to think about growth. Growth therefore became a slow organic process and not the accelerated highly impactful process it could have be.

Now I know differently, and we have just launched a revised growth cycle at Nolte. It looks like this:

  1. Q1:
    1. Objectives
    2. 360 mini-review
  2. Q2: same as Q1
  3. Q3: same as Q1
  4. Q4
    1. Objectives
    2. 360 min-review
    1. Promotions


We use the OKR (Objective and Key Results) framework to set both company and individual objectives on a quarterly basis. I find the OKR system allows for unrestrained thinking on your objectives as the objective itself does not need to be measurable, in fact the guidelines recommend you set audacious goals that will really stretch you.

I like to have my team self-evaluate against the job description of the next level up (see Promotions below), and set their goals around the biggest gaps. This way we are always working together towards the skills they need to acquire for promotion.

After that they need to think about how to measure that you achieved the objective, which can be tricky. I try not to get too bogged down in this with my own and my team’s KRs, and some of them end up as more experienced-based results. In other words you will know you’ve got there instinctively.

OKRs are measured on a scale of 0 – 1. A 0.7 or above is generally considered a good score, and 1 generally indicates that the goal was too easy. We set individual OKRs in the first week of each quarter, and then do a quick projection of the end of quarter score at the beginning of each month, which helps us see who needs help. The final evaluation is carried out at the end of the quarter.

360 Mini-Review

Many of us have taken part in the dreaded annual 360 review process. These are often drawn out affairs, which require some “popular” reviewers to lock themselves away for a whole day or more to work through endless lengthy questions. The feedback can be valuable, but is it worth the effort? And is an annual review really often enough?

I don’t think so, which is why we now run with a quarterly 360 mini-review process. The goal is to get feedback more often than an annual review, but with as little effort as possible. In the penultimate week of each quarter, every team member picks 2 peers with whom they’ve worked closely over the past three months.

In the final week of the quarter they are reviewed by:

  • Themselves (self-evaluation)
  • Their manager
  • Direct reports
  • The 2 peers (not repeating any of the people above)

The review form is simple and the guidelines state not to spend more than 10 minutes per person. On the form we ask the reviewer to evaluate the reviewee on each of our five core values, giving a rating (out of 5 stars) and a comment for each. The comment should explain what the person has done well and what they could improve for that value.

Finally, in the first week of the next quarter, everyone discusses their reviews with their manager. We don’t obfuscate the reviewers names or otherwise spend time preparing the results (we have a culture of open and candid feedback), we just go over the raw information. This information feeds into the quarterly OKR setting which happens at the same time.


In my experience, everyone needs to feel they are growing towards a target and will be rewarded for success. For Nolte, this was one of the major items we fixed last year. We first defined levels within the organisation as follows:

  1. Intern: New to the field, on the path to becoming an associate
  2. Associate: A professional able to take responsibility for delivering results without constant oversight from another team member
  3. Senior: Experts in their field and drivers of success in their pods
  4. Leadership: Drivers of success companywide and represent Nolte outside of the company

Each level has a base set of expectations tied to our core values. For example, we expect an intern to deliver value at a completely different level to a member of our leadership team. We also set salary bands for each level, which are the same for all roles within the level (we want to have a level playing field and consider that any team member in any role can deliver equal amounts of value to our clients).

We then defined job descriptions for each role within each level, eg for engineering we have Engineer (associate level) and Senior Engineer. These job descriptions go into the specifics of what is expected. See this article for an idea how I defined the Senior Engineer job description: What does it mean to be a “Senior” Engineer?.

Most people in the team now have a clear path, working towards the next level up from where they are now. Their quarterly OKRs are aligned to this. At the end of each year, managers compile evidence that show promotion candidates have met the requirements for the next level up, and the leadership team review and ratify the promotion decisions. Then, of course, we celebrate them!


The feedback from the team has been very positive, people now feel they have a sense of direction for their careers. The feedback they received from the 360 mini-reviews was also useful, especially the positive feedback as it reinforced how much we value our team.

Your Challenge: Ask your team how they feel about their career growth. Is there anything you could do to help them grow?

Engineers Build Solutions, They Don’t Check off Tasks

Software engineers thrive on problem solving. So why do we so often give them a list of tasks to check off?

I fell into this trap myself, the PMs in my teams used to attend meetings alone, document the requirements and break out tasks for engineers. I told myself we were “protecting” our engineers from dealing with all that pesky client communication, saving their time for the real engineering work. But I was very wrong. An engineer with a blinkered view of a problem cannot solve the problem, they can only do what they were told to do. They also are not really responsible for the result.

To get the best out of engineers, I’ve learnt they need to be involved from the beginning. They need to hear firsthand from the client what problem we are solving and why. They need the chance to ask the questions which come up in these conversations, and they need all that contextual information which is always watered down on secondhand meeting minutes.

It’s also not true that engineers can’t do this more analytical work, in my opinion it’s actually a fundamental skill of a great engineer. Trust your engineers to analyse and they will deliver. This is has been an important learning in my leadership journey. I also think it is an especially big problem in my home country of Mexico, where the management culture is very top-down. Many Mexican managers want control, they want to micro-manage, and they expect their staff to ask for permission on almost every decision. We often have to re-calibrate these expectations with new hires, because our culture is now one of individual responsibility and not manager-lead.

I use to work at Morgan Stanley in London, and back then they didn’t really have PMs. Just PMOs who would meet with one team member weekly to get the latest updates and manage a high-level view of the project. With hindsight I can see this forced us to self-organise by making their own decisions on what work was required and in what order.

To me, trust is large part of this. Trust that your team can deliver without you holding their hands, and they will. It will take some coaching / mentoring work to get there, but it’s worth it in the end. Who wants to work countless hours managing every detail of their team’s work? Wouldn’t you rather spend your time elsewhere?

Training & Certifications

This article describes some work in progress. I’m sharing to get feedback form the community and there are questions in bold. You can answer in the comments, by replying in social media or emailing me.

This is an oft misunderstood topic. I used to put a low value on training. During my time in tech I am mostly self-taught, figuring things out with the help of Google, reading documentation and generally looking to see how others have solved similar problems. This has worked for me on the whole, but on some occasions it’s definitely extended my learning period. Stepping out to take a course could have helped me understand some fundamentals sooner, which would have allowed me to build up my knowledge more quickly.

I have also come to learn through life that what works for me doesn’t necessarily work for other people (obvious, I know, but I was stuck in that rut for a long time). For some training is the best way of learning, for others like me, figuring stuff out in a more ad-hoc manner is our normal approach. I’m no expert in learning styles, but I’m sure there are many nuances to this. Our job as leaders is to allow our people to tailor their learning experience to their needs.

Certifications & Training Paths

Having said this, I also am aware that we need to level-up the skills of our team. I find most engineers, even senior ones, have gaps in their foundational knowledge. This is only natural in such a complex and dynamic environment as ours, but what can we do about it?

This is where structured certification or training paths come in. These gather together the knowledge you need to be an expert in a particular technology. They ensure you fill all the gaps, and in the case of a certification, they provide a nice certificate to prove that to your clients or future employers of your team members.

At Nolte we are working to put together a list of certifications or training paths to cover off on the requirements for different engineers. It’s still in its early stages, but I’d like to share some important ones:

In addition to the above we also expect our engineers to train on core web and engineering principles, such as performance, SEO, accessibility, security, systems design and engineering fundamentals like object-oriented programming.

And we expect training on the “soft” skills, which are so important to being a successful engineer. These include problem solving, technical writing, presentation of ideas, risk management, mentorship and business analysis. Do you know any certifications focussed on the general soft skills required by all engineers?

It’s not one-size-fits-all

Our training paths provide guidance, but it’s up to individuals to figure out what’s required with their managers. Certifications or the completion of a path are not necessary for promotion at Nolte, but they will help accelerate the process in most cases.

We’re still in the process of defining our training paths, any feedback would be wonderful. How do you organise training for your engineering team?

What does it mean to be a “Senior” Engineer?

Most engineers aspire to be considered “senior”, the title being recognition of their career journey and the value they can add to a business. However, I find there are many misconceptions amongst engineers about what it really means to be senior. In this article I’m going to lay out my perspective on what it means to be a Senior Engineer.


Let’s start with their technical skills. A senior engineer is an “expert” in one or more technologies. I put the word expert in quotes, because it in itself is a vague word. By expert, I don’t mean that they know every last thing about a language, framework, etc; and I definitely don’t mean that they need to memorise syntax or the like. An expert understands the fundamental principles behind the tool and can apply them to use the tool in the optimal way. The expert may need to Google solutions and they will likely copy and paste code from StackOverflow like the rest of us, but they will be able to quickly understand the explanations found by mapping them to their knowledge of the technology ecosystem they work in.

The expert’s knowledge also goes deeper than a given tool or language, they understand the fundamental principles of the programming paradigms they work with, eg object oriented programming. They also understand the related protocols and systems they need to interact with, eg a senior web engineer understands how information is transmitted over the Internet.

The Software Development Lifecycle

Top engineers don’t just know how to write well structured code, they know how to solve problems throughout the entire SDLC:

  • Analysis: they have the people skills required to proactively obtain business/technical knowledge and distill it into actionable points. They are not afraid to appear “stupid” by asking the seemingly obvious questions, they know that by doing this they are advancing everybody’s knowledge of the problem sphere. They make sure they understand as much as they can around the problem as they tackle it.
  • Design: senior engineers can architect a viable solution to the problem taking all the relevant factors into consideration, such as: budget (upfront and ongoing), maintenance, timeline, technical requirements, uptime, scalability, SEO, performance, accessibility and security. They use their creativity to think of and research non-conventional solutions to the problem at hand (they know writing code isn’t always the answer).
  • Implement: they build the solution whilst staying creative in the face of inevitable change. They maintain transparent communication with stakeholders as things change, they don’t leave people in the lurch by unexpectedly not delivering without prior communication.
  • Test: they ensure they release code of high quality, using a combination of automated and manual testing strategies depending on what makes sense for the project. They understand the different types of testing (unit, functional, UI, integration, etc) and when to apply them. Even if they work with dedicated testers, they still understand testing and still strive to deliver high-quality code for the testers.
  • Deploy: senior engineers know the feature is not complete until it is in production, up to that point things can change which add additional work or even make the feature obsolete. They do what they can to ensure their work makes it to production as quickly as possible, and they make sure things are setup to monitor that it’s working once it does.

Other Skills

Underlying the above are great problem solving skills, you can’t be a senior engineer without these. Solving problems in a great way means they (credit to Marc Backes for this list):

  • stay efficient
  • make sure not to introduce unnecessary sources of errors
  • create as little friction with the existing system as possible
  • think of the bigger picture
  • have expandability/reusability in mind
  • make decisions about potential trade-offs

In addition, great engineers understand the value of estimations as a tool for determining what is and is not possible for the given set of constraints. They use this tool to drive conversations with stakeholders. And of course, they have good communication skills (written and spoken) which they use to explain technical concepts and sell ideas, to both technical and non-technical people.

Finally, senior engineers can identify risks on their projects, they communicate them and drive them to mitigation. They are also team players, thinking about how to help their team mates grow into great engineers.

Their Purpose

Senior engineers understand that their job is not to write code. I’ll say that again – an engineer’s job is not to write code. Their job is to solve problems. Writing code is often great way of doing this, but it’s not the only way. Sometimes there are more optimal solutions, such as purchase a plugin or SaaS solution, leverage open source or even just tweak an offline process.

Many engineers don’t realise this. They focus on code as the only solution, and they are doing themselves and their businesses an injustice. How many countless hours have been wasted building solutions that didn’t need to be built?

Treat Your People Right

I strongly believe that work should be a fulfilling and even enjoyable part of each of our lives. We spend a lot of time working, and for many of us it is the main ways we contribute to our communities and society as a whole.

Like many companies, Nolte is a knowledge business, which means that the skill of our people is at the core of what we provide to our clients. Process and smooth talking is a difficult foundation on which to build a business, I know from the stressful experience I lived through. Having great people along with a culture of delivering great work is the only sustainable way. But it’s a two-way street, great people will only join and stay if you treat them right. This article explains some of the ways I believe we make a difference.

Treat them like adults

You hire people who are responsible of delivering great work. You expect them to proactively identify risks, communicate with the client, design solutions and implement them. Yet you treat them like children!

This is a particular bug-bear of mine in my home country of Mexico, where it is common to have strict controls over employee’s time (you must be at your desk by 8:30am and leave at 6pm, you have 1 hour for lunch from 2-3pm, no slacking!). Added to this are expectations that you will work late when necessary, but nothing is given in return (Mexico actually has the longest working week of any country in the world). My wife, Ellie, used to work for an insurance company many years ago and at month-end her team would be waiting until mid afternoon to receive the data they needed to run their processes late into the night. This would go on a for a few days every month, she would arrive home as late as 3am and be expected to be in the next day at 8:30am, just to kill hours doing nothing whilst waiting for the next day’s iterations. WTF? This is bureaucracy gone mad, how does this strict time keeping only work one way? How do you expect your staff to think on such little sleep? Never mind the impact on their health and family life. Unsurprisingly, she quit.

My view is that the type of adults we want to employ can organise their own time. We don’t dictate any start, stop or break hours. We don’t even have any limits on vacation time or where you work from. We trust our team to do the right thing for themselves, their team mates and our clients.

Bend over backwards to give them what they need

To start with, your team needs the tools of their job: a computer. Get them a good one that will help them be as productive as they can. On top of that they need a great working environment, whether that be office space or home office – it should have the resources they need to be comfortable, productive and healthy.

They also need growth, few people are happy to stagnate. We sponsor training and are working to define career paths for all of our team. We go above and beyond, for example providing regular English lessons to a number of our team members. And of course be generous with your time and expect the rest of the team to do so too, our job is to enable our teams to grow, not just to deliver for our clients.

This is really the base level. From there I am present to the fact that work is an integral part of our lives, not something to be balanced (implying a never-ending battle between work and home life). Invest in your team’s wellbeing, and support them in their family lives. We provide health insurance for the whole family, an allowance to spend on wellbeing, plus we run initiatives to understand how our team our feeling and take action where needed.

The final part is where we really bend over backwards. Say an employee comes to you with a personal problem, what do you do about it? Regardless of whether you consider it directly impacts their work, let’s use our resources to support our team. And let’s go one step further, by proactively asking our team members what their personal goals are, let’s not limit ourselves to professional goals. I view us as one big team in life, our shared goal: a fulfilling and successful life for all Nolteñ@s.

Share the spoils

Celebrate success, both in work and personal lives. Be generous with positive feedback, and expect your team to do so too. Be generous with your cash, your people helped you earn that.

One nice thing in Mexico is the PTU, which legally obliges companies to share 10% of their profits with their staff. At Nolte we have extended this to include all employees worldwide, considering the company’s worldwide profit. This has the added benefit of aligning your team to your goal of a healthier bottom line.

In Summary

Treat your staff right and they will treat you right. They will do great work and they will stay loyal. And you may feel good about the impact you’re making on the world.

The Focus of a Smooth-Running Technology Organisation

A couple of months ago I wrote about What Technology Leadership Means To Me, describing my journey during 2020. But what does the current state of our technology organisation look like?

A Focus on Our Clients’ Goals

Our philosophy is to co-create digital products with our clients by solving problems in a way which makes sense for them. Of course, we expect our engineers have exceptional technical skills, that’s a given, but on top of this we expect them to understand how to analyse the business requirements and look for an optimal solution. Writing code isn’t always the best way to solve a problem given the constraints on budget, time, etc.

Our engineers now often hear me ask “why?” when they share a plan. I really want to make sure they know why the customer needs the feature, because that way we have the opportunity to provide real value in the form of a better solution. Our vision is not to be a dev shop which simply churns out work on a client’s request, but to partner with them to achieve their goals. We have a wealth of technology experience in our team, which should augment our client team’s business knowledge.

A Focus on Ownership

Each team member owns their work now, it is not “fed” to them by a project/product manager. Before the PM would gather requirements and even break down the work into tasks, and the engineer could feel they had succeeded by simply checking off the work assigned to them. Not anymore, now our team agree acceptance criteria with the PM / client, and are responsible for delivering on these within the time, budget and other constraints defined; or communicating that it isn’t possible so we can have a conversation around it. This principle comes from the excellent Shape Up book by Ryan Singer of BaseCamp.

We have also recently switched our Agile methodology from Scrum to Kanban across the company. The focus here was on reducing the overhead of agile ceremonies and more closely modelling our methodology to how we are actually work (before we said we were working in Sprints, but that was not the reality). This has shifted the focus of the team on delivery (always take the task closest to the finish line) and improved the efficiency of work (no need to wait for a PM to assign work, just pick the highest priority available task).

A Focus on Team

As a service-based business, our company is all about people. And that’s where our focus should be.

Our conversations are now around how we can best support our people to grow, a 180 degree shift away from the previous conversations around what was wrong. A breakdown is now an opportunity to learn, our leaders have developed a keen ear for opportunities in this department, and best of all it happens without me even being involved.

I’m delighted that our engineering leads (shout out to Nelson and Oscar!) are proactively working with their teams to produce better products and websites, and most importantly investing in their team’s growth.

A Focus on Strategy

These changes have freed up my time to focus more on the strategic direction of our technology. I am working on such things as structured career / training paths and new technologies we can experiment with adopting. On a personal level, I am also starting to explore how to expand my leadership beyond the team and into Mexico and the tech industry globally.

What Technology Leadership Means To Me

I’ve spent the last few months working with a business coach, digging deep into what leadership means to me. In this article I briefly share my journey…

My views on leadership have changed dramatically since I suffered a leadership breakdown at the end of 2019. In short, back then it seemed nothing I did made a difference to the results we got as team. Wins were few and far between, and it seemed no matter what I said, nobody listened. My coach made me realise this was all down to me, not my team. I needed to take complete responsibility for our work, I couldn’t blame one team member or another for not performing or not knowing something I thought they should.

Fast forward a few months and I feel a lot better about my work and, judging by their feedback, the team does too. Our company financials are also healthier than they have ever been, which is large weight off my shoulders!


One big change is my focus on breakthroughs rather than incremental improvement (which is the default for most people, me included). For me this is largely about giving myself permission to do something different and having the courage and tenacity to follow through. My 2019 way was to work in near isolation on new ideas, explain them to the team and then leave them largely to their own devices. Not anymore, now I drive through the changes I believe in by working with the team to experiment with new ideas until they are ready to run with them.

Vulnerability is another of my weak points, and one I’ve worked to develop. Sharing with the team that I want us to try something, even though I don’t know it will work, is one way I’ve expressed this. I’ve been delighted to receive feedback that they have trust in me to work together on these things. I’m also used to being “right”, and my tendency is to take over meetings instead of listening and working together to come up with the best solution. I continue to work hard at speaking less and listening more in meetings, it’s not easy for me.

Leaders Create Leaders

What does it mean to be a leader? For me a key principle of being a leader is creating other leaders. In order to grow as a leader myself I needed to give opportunities for my team to lead. We already had a group of senior engineers identified, with some expectations beyond that of our other engineers. But these expectations were unclear, and the senior team certainly did not have the support they needed from me. So I took these engineers and structured a formal Engineering Leadership Team.

The new team has a clear responsibility: each senior engineer is responsible for the work of the engineers in their pod. And I am responsible for the work of all engineers in our organisation. My vision is for the senior engineers to completely own their pod’s work, using me as a high-level resource when needed.

I also realise I am asking these senior engineers to do something they don’t have direct experience in doing, and I don’t expect them to just pick it up and run with it on their own. I’m taking on coaching and generally working with them with the aim of fully implementing my vision within three months.


Recently I did some reading on what it means to be a leader in a technology-driven organisation. I discovered an important part of a leader’s job is knowing when help is needed and judging how deeply they need to intervene. This is where metrics come in. I setup Velocity and enlisted my senior engineers to work with me, using the tool to identify where conversations need to happen with our team members

Another realisation I had is my tendency to make excuses for people. Instead of being clear with myself that so or so is not meeting expectations, I would make it about me: am I setting them up for success? am I communicating my expectations clearly? This meant that I would not give feedback with conviction, how could I if the issue may be with me and not with them?

This simple piece of self-awareness has made it possible for me to give direct feedback to my team. Coming from a context of caring about them (check out Radical Candor by Kim Scott for more on this), this has allowed me to have meaningful conversations with team members where we work together on their growth.

What This Means For Me

Being a better leader means we produce better work, work I can be proud of. The team is happier, they are a team I can be proud of. And I spend less time fire fighting and more focussing on things that add value to the business. Most importantly of all, I’m able to keep my work life within the boundaries it belongs – less working late or weekends, less thinking about emails or problems in my leisure time. Which means more quality time with my family.

I’d love to hear about your journey too, do please share.

Planning to a Budget

A new project, a new tech, a chance to build something better than I’ve ever built before. I’m sure all engineers have felt something like this when starting a new project. But then the constraints come along, and our enthusiasm is dashed. Unless we view these constraints as an opportunity for creativity! Read on…

One of my main responsibilities as a technology leader is to ensure we meet out clients’ goals without breaking their budget. This is tough, clients often have high expectations of what can be built in a given timeframe and budgets are usually tightly managed.

I don’t feel I have a perfect solution to this problem, but this article explains what I’ve learnt in almost 20 years in technology of which the past 8 have been spent in client services.

The Beginning

By the time we start thinking about technology, the client should have some idea of their brand. They generally know what problem they are trying to solve and have done some studies into the viability of their idea (if not we guide them through this process first). So let’s assume we know who the audience is and what problem they need to solve.

At this stage we want to bring in senior members of our team to help guide the conversation. Usually the client has big ideas about what their product will look like and we need to guide with some questions, like: what is actually a necessity for launch? what would a successful launch look like? We’re thinking along the lines of a Minimal Viable Product (ref The Lean Startup by Eric Reis). We emphasise that we won’t compromise on the quality of the user experience, in most cases we believe the risk to the brand of a subpar experience is too high and could damage it permanently (plus it doesn’t reflect well on us!). At this stage we’re talking about high-level features that are essential versus those that could be dropped, simplified or pushed down the line.

A simple technique we often use for this is the MoSCoW Method which groups features into buckets of Must Have, Should Have, Could Have and Won’t Have. We’ll work through this with the client, at the same time building up a better understanding of the constraints, assumptions and risks around each feature.

The Technology

Once we know what an MVP could look like in terms of features we can start to map technologies onto them. I like to start with the core of the user experience, usually the web or mobile app. Throughout this process I’m trying to get the biggest bang for their buck – how can we build as quickly as possible a solution that meets the requirements, meets the budget and won’t cause a nightmare for our team in the near future? What are the short- to mid-term implications of these decisions?

We have some go-to technologies in our toolbox, such as WordPress, Laravel and the Google Cloud Platform, but I also like to look outside of these. We all know that technology changes faster than anyone can keep up with, and it’s important to consider new solutions, even for old problems.

I also like to keep this process as collaborative as possible, both internally within our team and with the client stakeholders. After all, our job as engineers is to solve business problems, and how can you solve a business problem without collaborating with experts in this business? Inevitably there are trade-offs to be made and by iterating in small steps we can gather feedback and switch course as we go, wasting less time going deep on solutions that won’t work.

This in itself is worthy of a deeper mention. Our clients have different levels of experience with technology, some come from similar agency or technical backgrounds or are used to working with agencies like us, and just get it (though this can have its own perils). Others do not, and there’s the whole spectrum in between. There is some judgement required based on our experience as to how much information a client needs to make a decision, but in all cases they need to understand the business impact of the options in concrete terms.

Agreeing Appetite

Once we have defined the high-level architecture, we start to go deeper into each of the must have features. The goal is to agree a budget (or “appetite”) for each. Recently I’ve been using a process adapted from the Principles of Shaping and Setting Boundaries chapters of Shape Up (by Ryan Singer).

Based on the knowledge I have already gained, I will define the following for each feature. I’ll go to Nolte team and client for questions as I go, but this is largely a solo exercise:

  • The Problem: What is the problem we are trying to solve? By clearly defining this we focus the rest of our work and set boundaries for the team as they work on the feature. Without this, it becomes hard to make decisions on whether certain elements of the feature are critical or not. But with this we can always ask the question: is this requirement necessary to solve the problem?
  • The Solution: Here I’m defining at a high-level what the proposed solution is. Generally this will link back to the high-level architecture (which components of the architecture come into play?) and will define the key parts of the solution without going into detail with wireframes or the like. The idea is to set boundaries without directing the team too firmly as this will stifle creativity further on.
  • Rabbit Holes: Identify any parts of the solution I see as risky, particularly where there is a risk of team going down a hole that over-complicates the work. A recent example is the implementation of recurring payments with Stripe, in this case I clarified that we won’t allow users to store multiple credit cards on file.
  • No-gos: Anything identified as definitely not included in the solution. For example, in the same product I stated in the order management feature that we will not handle payment failures in the system, there would be a simple notification to customer support who will handle them offline.
  • Appetite Range: Taking all this information into a client meeting and expecting them to make a decision on how much they want to spend on each item is unreasonable. Most of our clients don’t know how much things cost and can’t imagine what they may get by spending less or more on a given feature. So I set a range of high/low appetite (we use team days which translate to dollars) based on what I think is reasonable for the feature. I like to leave these ranges quite wide to provoke discussion around what they may get for the high price vs low, but at this stage we don’t make any commitments.


Armed with this data I setup a workshop with the client team to work through the list of must haves. Generally you will need half a day or so for this, or 2-3 shorter meetings. The aims of the workshop are twofold: agree an appetite for the feature and align on the information that I’ve written. I expect there to be some changes, new edge cases or otherwise new information that goes into the list, and often there are some follow-ups for me and/or the client to dig into. By the end of the workshop we should have agreed an appetite for 90% of the features and know what is needed to finalise the other 10%, which we either do via email or in one further call.

Shared Responsbility

One really important goal of all this is to get the client onboard with the way we work. We don’t estimate the features upfront, I fundamentally don’t believe it is possible to do so accurately (is the phrase “accurate estimate” an oxymoron?). We all know that technology is complicated and the one thing we can be 100% sure of is that things will change (normally a lot) during the build.

This is why we use appetite and not estimates. We want the whole team aligned on the question: how can we get this feature done within the agreed appetite? It’s only possible if all parts of the team pull together: engineers, QA, design, client, etc. We want to foster creative thinking amongst us all, to get the best result for our client without breaking their budget or sucking up a massive overrun ourselves.

How does your agency approach this? I’d love to hear via twitter, @adamf321, or in the comments below.