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.

5 Tips To Stay Focused In A Distracted World

As someone who has struggled with distractions, I’ve always looked for ways to improve the way I spend my time.

Running a business is demanding but can also be extremely rewarding if your time is managed properly. When I did not manage my time properly I made personal sacrifices which resulted in resentment towards the business. After years of trying exploring techniques to balance my time my relationship with the business has greatly improved resulting in a healthy work/life balance.

The Impact of Distrations

In an article from Atlassian, the illustrate how much of negative impact distractions in the workplace have.


Interruptions per day for the average employee


Minutes spent working before the average employee switches tasks


Hours spent on average recovering from distractions per day


Percentage of distractions per day that are considered trivial


Times the average employee checks their email in an hour


Minutes spent refocusing after handling an incoming email.

I’ve personally experienced much of the above and recall a time where my day would take complete ownership of my life due to allowing myself to get distracted and external factors control my time. The following are some of the easy and accesisble tips that I’ve found to help me live a less distracted life.

1. Meditate

One review of 23 different studies found that in general, people who’ve been meditating for just a few months perform better on tasks that test their ability to shut out distractions, while longer-term meditators show a markedly improved ability to maintain focus for especially long periods of time.

  • Use an app like Headspace
  • Practice regularly, ideally daily
  • Reward yourself for practicing consistently

2. Create a Distraction-Free Environment

Invest time in removing distractions from your working environment to optimize how your time is spent. Distractions can come from people, devices, and yourself.

  • Turn off notifications
  • Turn off / stash cell phone
  • Keep a tidy inbox
  • Block task time in a calendar
  • Work offline
  • Keep a tidy workspace
  • Inform others to not disturb

3. Use Timeboxed Intervals

Timeboxing is a heads-down approach to focusing on a task within the confines of time. Timeboxing can be used for both work and play. Timeboxing Much relates to a psychological principle called Parkinson’s Law, which states that work will expand to fill the time you allow for its completion.

  • Use your calendar
  • Commit to the start/stop time
  • Timebox leisurely activities and work

4. Plan Your Objectives

The simple concept of planning combined with other methods will drastically help you both set and reach your objectives. Breaking down your tasks and prioritizing what will be most impactful ensures you will close out your day feeling fulfilled resulting in less stress.

  • Plan before starting anything else
  • Prioritize don’t over commit
  • Focus on one large or 2–3 smaller tasks per day
  • Use estimations to assess tasks
  • Identify and focus on dependencies first

5. Limit Work In Progress

Leveraging from production and agile methodology work-in-progress or WIP refers to the number of tasks being worked on at one time. When focusing on starting a task and driving it to completion you can accomplish more. This method eliminates the buildup of tasks and bottlenecks.

  • Define what “done” means for a task
  • Break large tasks into small ones
  • Close other windows/apps
  • Use a todo app or task manager

In summary, there are a million ways to get distracted and many effective ways to avoid getting distracted. Building a healthy practice in which you learn from your failures to develop healthy habits can be immensely impactful for living a fulfilling life.

A value of ours at Nolte is to Help Others Grow. To embrace this value, each member of Nolte produces content for Nolte Lightning Talks on our YouTube channel. This article is an excerpt from my lightning talk presentation (video below)

Have a great tip on how you stay focused or have any questions for me? Leave a comment below and I reply ASAP.

Deep Work- The Right Mindset in a Distracted World

“In a world of distraction being able to focus is a huge competitive advantage”

Taylor Otwell (creator of Laravel)

Image of a developer looking at his big screen practicing deep work, focusing in one job at the time

According to best-selling business author Cal Newport and many other field experts, one of the biggest challenges in today’s society is staying focused. Every day, we have countless emails, Slack messages, Whatsapp, Jira tickets, tweets, notifications, the list goes on…

We need a to-do list to process our to-do lists; we need a break to process all of that information. There is a common misconception about multitasking: we think it’s efficient to do a lot of tasks at the same time; in reality, we are delivering ordinary or sub-par results. Working individuals need to go deeper to achieve notable outcomes, and deep concentration is the key to create new values and improve skills.

Before engaging with how to best perform “deep work” as a team, we spent about 60% of our time doing shallow and ordinary work. Now, we’ve examined the problems of shallow work, and created processes that encourage deeply focused, highly effective work here at Nolte. Read on to learn more about how to instill this focus within yourself or your team.

What is Shallow Work?

Shallow Work put simply, is distracted work. According to Evernote’s blog, we unlock our iPhones an average of 80 times daily and rack up more than 4.7 hours actively engaged with our mobile devices or instant messaging apps each day.

When we check our emails and instant messaging apps every minute, we experience a fear of missing out, or “FOMO” as the kids call it. This illustration of FOMO helps me and our team, remember to let go of the constant demands of being “plugged in” 24/7. Let go of the FOMO, and embrace experiencing the moment you’re in, which will allow you to work, play, and live more productively— plus, you’ll enjoy yourself more.

“Non Cognitively demanding, logical-style tasks, are often performed while distracted. Their efforts tend to no create much new value in the world because they are easy to replicate.” – Carl Newport.

Rules to Deep Work

From experience working at Nolte, I’ve come up with a set of rules to practice deep work when we’re doing our projects:

1. Use network communications wisely.

According to Newport’s book, if we stop an important task to attend to some other task, we could need about 20 minutes to recover our full concentration in the main task. If we stop every five minutes because we get a new push notification, email, or ping, we will produce only ordinary results for our customers, bringing back the shallow work practice.

When you are trying to create new value, and want to accomplish something or improve your results in your current job:

  • Avoid instant message applications
  • Put your phone in no-disturb/night/sleep mode, and
  • Disable distracting mobile phone notifications
  • Try to go deep with your full attention at least for 25 minutes with NO interruptions. Need some help to practice this? Try the Pomodoro Technique.

If you still can’t focus, then you can try something that has helped me with focus. It’s an innovative interactive game called Forest App. The less you use your phone, the more the app rewards you, through the visual tool of planting and growing trees in a forest. It’s a great starting point for people who find their phones addicting, and it’s helped me in my professional journey.

2. Avoid multitasking when possible

When you try to do two or more different things at the same time you are going to discover the fraud that is the multitasking approach; certainly, you can simulate “good” progress in your duties, but you are not delivering the best quality that you could deliver if you go deep. There are quite a few apps that give you the option to go full screen or offer you a “distraction-free” mode. Utilizing these tricks and tools, when available, is a great way to foster focused working, and great idea development.

At Nolte, we use Jira Boards to assign tasks for every person in the company. It’s not a surprise that the best practices of the Agile methodology suggest that you should only have one task in the “in progress” column because, think about it— our minds are not designed to multitask. We have might have two eyes and two hands, but we only have one brain to process what we are doing. By working on one thing at a time, we can create more opportunities for deep work as a team.

As Newport said, to remain valuable in our global economy, you must master the art of quickly learning complicated things. This task requires deep work. If you don’t cultivate this ability, you’re likely to fall behind as technology advances.


Digital tools are getting more complex day by day and it’s hard to follow their pace. However, this is something we must keep learning and practicing. Only then, we’ll be able to use new, advanced tools to their full potential. So keep learning, keep doing complex things, cultivate the power of concentration and you will be rewarded with new discoveries every day about your job and your capacities.

At Nolte, we trust in our team and its capabilities to choose the right time to go deep, and we enjoy the results of this process: delivering meaningful and unique products to our clients.

So, what is more important to you? Your team’s goals and aspirations, or the meme messaging on your Whatsapp group? Remember, the goal of deep focus is not to ignore every opportunity to communicate, but to choose the right time to do it. Give yourself time to do both, and you’ll find you need to do them simultaneously will disappear.

What else?

Develop your business culture around keystone habits.

Empower your business with empathy to improve the relationships with all your stakeholders.

We see real value in the hiring process for web engineers. Learn how we do it.