Lost and forgotten nuggets of ideas and advice

via GIPHY

I’ve been blogging for so long, sometimes, I forget about all the old material I’ve written.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

And I was just recently digging through some of the old titles, and thought it would be fun to repost some good ones.

1. What is it, and why is it important?

Infrastructure provisioning, what is it and why is it important?

Root cause analysis – what is it and why is it important?

Zero downtime – what is it and why is it important?

Stress testing – what is it and why is it important?

Data spot checks – what is it and why is it important?

Service monitoring – what is it and why is it important?

Decoupling – what is it and why is it important?

Read: What did Matt Ranney discover scaling Uber to 1000 microservices?

2. Thought provoking

Is AWS too complex for small dev teams?

The myth of five nines – Why high availability is overrated

Why are generalists better at scaling the web?

How to hire a developer that doesn’t suck?

What 5 things are toxic to scalability?

Is there a 4 letter word dividing dev and ops?

Related: Can humility help you in your career?

3. Consulting

Can progress reports help engagements succeed?

How do you handle the onboarding of a new engagement?

Why I ask clients for a deposit

How to avoid legal problems in consulting?

How best to do discovery in cloud devops engagements

When you’re hired to solve a people problem

When you have to take the fall

When clients don’t pay

Read: What happened when I offered advice outside my pay grade?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

When can I count time as project time?

via GIPHY

I was on the train looking at a Monday.com ad. I realized that the project management space is not dead and buried, but continuing to evolve everyday. While many of us spent years using tools like Jira, along comes an upstate to make project tracking simpler.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

The trouble is, I never felt it was the project management software that made tracking difficult.

For me there was always endless nuance, around tasks and tracking.

1. Time spent commuting or thinking off the chair

For me, when I get deep into the weeds of a customer and their technology stack, I’m thinking about problems as soon as I wake up. How can I tag those resources so they are region independent? How can I create the right S3 bucket policy so the application can write, but the world can’t?

What’s more if you’re like a lot of people, there’s some slack going on after hours, and emails too. Some of this may get tracked but inevitably there are hours not tracked.

An amount of estimating will probably happen. And creating a team policy on how to handle this ambiguity, is probably a good plan. Each project and company will be different, in terms of where to draw the line.

Read: What did Matt Ranney discover scaling Uber to 1000 microservices?

2. Crossover between projects or even customers

Sometimes there is a task which requires a bit of research, for example what’s the exact syntax in Terraform to create an IAM role, and attach it to an instance? You may spend an hour digging in, and then experimenting, to make sure you have the code right.

Then you may use that same snippet on another stack that you’re building, for department B and the same company, agile team C, or another customer entirely.

When you think about it, you carry a decade of learning into each new customer you work at. And they get all that learning, which translates into efficiency. And that’s effectively free.

So there is all sorts of ambiguity. And in each case you have to make a judgement call, when you’re tracking time.

Related: Can humility help you in your career?

3. Tasks grow and change

As you continue to work on a project, some tasks have a tendency to themselves unwind. As you dig deeper, you find vast caves yet to be explored. More excavation that needs to be done.

From there subtasks may hatch from the parent, and on it goes. But this will surely blowup initial estimates, and makes tracking progress often more of an art than a science.

Read: What happened when I offered advice outside my pay grade?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

How do we make domain decisions when coding software?

via GIPHY

I stumbled on an interesting discussion over at hacker news about when you have to make a decision in code outside of your domain of expertise.

This is a super interesting topic to me. As the world is more and more powered by computers and algorithms, this seemingly obscure philisophical corner of computing begins to affect us all.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

While many programmers are familiar with the experience of stumbling upon an edge case which wasn’t covered in the spec. The truth is you can’t go back and block on every single tiny detail.

Some of the bigger ones can trigger further discussion, but were it not for Falsehoods programmers believe about X the software would never go out the door.

Here’s some more food for thought…

1. Falsehoods programmers believe about names

o They won’t be a *bad* word. Whose bad? i’m not sure.
o All people have names.
o We only have to work with names from English.
o Names are ordered in a sensible manner.
o A name won’t have to change later.

You get the picture. As you start working with the minutae around names, you realize there is a lot of assumptions. Even when you weed out the big ones, there are still small assumptions.

Ultimately, you can’t get to the bottom. There will always be some assumptions, and as software evolves, changes will be required to match the real world. Living systems grow. Software systems must receive *updates*.

Read: What happened when I offered advice outside my pay grade?

2. Falsehoods programmers believe about selling products

o each product has a price
o each product has one price
o each product is one unit
o two decimal places is enough for all currencies
o all currencies have a unicode symbol

There are many more. The point is once you start digging, everything gets fuzzy. Products can be in stock and not in the warehouse. Single product can have multiple prices. It goes on and on!

Read: What did Matt Ranney discover scaling Uber to 1000 microservices?

3. Falsehoods programmers believe about addresses

o two districts will not have the same number
o postal codes will agree across jurisdictions
o a fixed number of characters will work for every address
o roads have names
o buildings are not numbered zero

Addresses are *really* messy. I remember being surprised when I moved to brooklyn. Streeteasy & Google put me in different neighborhoods. I asked my lawyer why this was. He said DOB and the post office use different databases. And google further samples from one or the other.

Never the twain shall meet!

Related: Can humility help you in your career?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

What do senior engineers do differently?

via GIPHY

I recently stumbled up on this piece at Pivotal, The art of interrupting software engineers. It caught my attention because i like to read from a different vantage from my own.

What is it like to interrupt us?

Join 35,000 others and follow Sean Hull on twitter @hullsean.

What I really got from the article though, was how different types of engineers will think about problems differently.

1. Under the hood

For junior engineers who are still a bit green, and new to working in industry, they’re downward facing. Focusing solely under the hood, they may not see how their work contributes to a product, or how it fits into the overall picture for the business.

“When asked about their progress on a story, they would make an effort to ensure I understood what was happening under the hood and what tradeoffs they were facing using a vocabulary I was familiar with. ”

For her it was technical competence that stood out – or at least not the only thing – but rather how they were strategizing, and communicating their problems, challenges, and progress.

Read: What happened when I offered advice outside my pay grade?

2. Communicate discoveries

A more intermediate engineer, would sometimes anticipate & communicate better.

“In some cases, those engineers would come to me before I even had a chance to enter the paranoid zone and give me a simple explanation of how the team had learned new information since they first estimated the complexity of a story. ”

She is also speaking of situational awareness. So not working in a vacuum, communicating & incorporating that new information as it becomes available.

Read: What did Matt Ranney discover scaling Uber to 1000 microservices?

3. Anticipate in advance

Senior engineers, she says would really stay ahead of the curve. They were even anticipating what might be a roadblock for her product delivery.


“Some of the very best practitioners would ask me in advance how urgently we should deliver a particular user story and what we were ready to give up in order to ship faster.”

Weighing tradeoffs, and prioritizing is a huge factor in velocity. If you can tame that beast, you’ll go very far indeed!

Related: Can humility help you in your career?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Viktor Farcic Interview excerpts

via GIPHY

I recently did an interview with Viktor Farcic all about operations, DBA & Devops. Here are some excerpts: What does Dev-Ops mean?

Join 35,000 others and follow Sean Hull on twitter @hullsean.

Continuing where I left off, I’ve included a few more highlights below. Enjoy!

1. Can I use a tool to migrate to the public cloud?

Viktor Farcic: I’ve seen quite a few of these tools that tell you if you buy our tool, we’re going to transfer whatever you have to the cloud. For example, Docker announced in the last DockerCon that they’re going to put in containers without a single change and everything will work. What do you think about that?

Sean Hull Salespeople often simplify things quite a bit in order to sell a product; in my experience, the devil is in the detail. It’s not to say that an automation tool like that might not be valuable and useful. It might be a good first step to getting your application in the cloud, and it might be an easier way than to rebuild everything one by one. But I doubt that it’s going to work magically just by one script.
EC2 instances, for example, have different performance characteristics, not only in terms of the disk I/O, memory, and CPU, but in smaller instances, they actually throttle the network access so you might spin up an instance and it just might not behave well. It might take time. In fact, all sorts of things could happen. You might have written MySQL scripts that assume you have root access to the server and then you rebuild that in an RDS and you get errors because you don’t have access to those resources on RDS. There’s a lot of things to consider.

Read: What happened when I offered advice outside my pay grade?

2. How do you adapt to change?

Viktor Farcic: I have the impression that the speed with which new things are coming is only increasing. How do you keep up with it, and how do companies you work with keep up with all that?

Sean Hull: I don’t think they do keep up. I’ve gone to a lot of companies where they’ve never used serverless. None of their engineers know serverless at all. Lambda, web tasks, and Google Cloud functions have been out for a while, but I think there are very few companies that are able to really take advantage of them. I wrote another article blog post called Is Amazon Web Services Too Complex for Small Dev Teams? where I sort of implied that it is.
I do find a lot of companies want the advantage of on-demand computing, but they really don’t have the in-house expertise yet to really take advantage of all the things that Amazon can do and offer. That’s exactly why people aren’t up to speed on the technology, as it’s just changing so quickly. I’m not sure what the answer is. For me personally, there’s definitely a lot of stuff that I don’t know. I know I’m stronger in Python than I am with Node.js. Some companies have Node.js, and you can write Lambda functions in Java, Node.js, Python, and Go. So, I think Amazon’s investment in new technology allows the platform to evolve faster than a lot of companies are able to really take advantage of it.
Read: What did Matt Ranney discover scaling Uber to 1000 microservices?

3. What is the future of Devops?

Viktor Farcic: I’m going to ask you a question now that I hate being asked, so you’re allowed not to answer. Where do you see the future, let’s say a year from now?

Sean Hull:
I see more fragmentation happening across the technology landscape, and I think that that is ultimately making things more fragile because, for example, with microservices, companies don’t think twice about having Ruby, Python, Node.js, and Java. They have 10 different stacks, so when you hire new people, either you have to ask them to learn all those stacks or you have to hire people with each of those individual areas of expertise. The same is true with all these different clouds with their own sets of features: there’s a fragmentation happening.
Let’s look at the iPhone as an example. Think about how complex application testing is for Android versus the iPhone. I mean, you have hundreds of different smartphones that run Android, all with different screen sizes, different hardware, different amounts of memory, and the underlying stuff. Some may even have some extra chips that others don’t have, so how do you test your application across all those different platforms?
When you have fragmentation like that, it means the applications end up not working as well. I think the same thing is happening across the technology spectrum today that happened 10 to 15 years ago, where for your database backend there was Oracle, SQL Server, MySQL, and Postgres. Maybe somebody who’s a DB2 enterprise customer uses DB2, but now there are hundreds of open source databases, graph databases, and DynamoDB versus Cassandra, and so on and so on. There’s no real deep expertise in any of those databases.
What ends up happening is you have cases like what happened with customers who were using MongoDB. They found out the hard way about all of the weird behaviors and performance problems it had, because there just weren’t people around with deep knowledge of what was happening behind the scenes, whereas in Oracle’s space, for example, there are career DBAs that are performance experts that specialize in Oracle internals, so you can hire somebody to solve particular problems in that space.
There aren’t, as far as I know, a lot of people with MongoDB internals expertise. You’d have to call MongoDB themselves; maybe they have a few engineers that they can send out, so what’s the future? I see a lot of fragmentation and complexity, and that makes the internet and internet applications more fragile, more brittle, and more prone to failure.

Related: Can humility help you in your career?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Consulting outside my pay grade

via GIPHY

I recently worked with a customer migrating to Azure. Part of the plan was to take advantage of various free credits available on Azure. That’s not a bad reason cost wise, as long as the engineering cost of migration is considered.

Then I dug further…

Join 35,000 others and follow Sean Hull on twitter @hullsean.

Sean: Why are you migrating to Azure?
Customer: We’re getting free credit from Microsoft. Also we must not have any services on AWS.
Sean: Why is that?
Customer: We are trying to close to a deal with Walmart. Of course they’re a big fish for us and we don’t want to lose them.
Sean: Ummm… let’s take a closer look at that.

o we need to migrate because our future customer is in a pissing match with AWS
o sales should not blindly drive tech decisions
o there will always be some things on AWS
o if you’re going to be non-technically pure then just say yes we have *everything* off of AWS and keep running your business
o if sales can lie, then go ahead and blow the smoke up there

You can’t be completely free of AWS

While the sales team thought that was a simple directive, they forgot a few details.

1. There is a financial cost to the business to migrate from AWS to Azure
2. There is a technical risk of migrating from AWS to Azure
3. There are hidden and unforeseen technical costs as things fail, or code unravels.
4. As you have THIRD PARTY apps, you are using AWS, such as Slack, Salesforce, Zoom, Dropbox, Jira and perhaps many others.
5. Internet traffic flows through aws networks.

Read: The myth of five nines – why high availability is overated

Sales & engineering have different mandates

Sales teams are driven in a different way than engineers. Their day-to-day is about closing deals, and so priorities are different. What’s more the grasp of technical minutiae may not always be as deep.

This is not a criticism, more an observation. So too engineers don’t understand the realities of sales, and closing deals.

That said you get into the danger zone when sales driven calculation pushes the business to make a bad decision.

The engineering marvel is what holds up the bridge. So it doesn’t make sense to skip the inspections, or leave out trusses because a customer said the bridge will look prettier that way. The engineers must have serious input on technology decisions.

That will then help the business make a balanced decision, one that considers the true costs involved.

Read: Relational Database – What is it and why is it important?

Engineering & Sales should be cooperative

One should not outweigh or outmuscle the other. Their needs to be a balance of concerns. A big chunk of business that doubles the underlying revenue may be worth large tech stack changes.

But there is also a risk that the house of cards comes tumbling down. Even if the reengineering risks are managed, the new debts owed by Rome could still take you down.

Related: Why generalists are better at scaling the web

How does pay grade come in?

In the above case I was hired to do a migration. I wasn’t hired to think strategically about the business.

So some might argue that is stepping outside the mandate or scope of work. That said I do try to offer opinions where they make sense. In this case it may be of value to the business.

However, since it is “outside my pay grade” I would offer it humbly, and gently. No sense shooting yourself in the foot. 🙂

Related: Why generalists are better at scaling the web

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Can humility help engagements succeed?

via GIPHY

I was reading this article on Vox recently titled Intellectual Humility: the importance of knowing you might be wrong.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

It caught my attention, and I think we can expand on it a bit. Here are my thoughts.

1. Admitting when you’re wrong

Of course we’ve all had moments when we’re wrong. We make a proclamation, which turns out wrong. We measure something incorrectly. Or we forecast imprecisely.

It is hard to stand on the stage. The spotlight is on you. And when you do that you can be the object of criticism, and speculation. Just like everyone you may make mistakes, but when the spotlight is on you, it can weigh heavier.

That is exactly the time to be a bit humble, acknowledge your thought process, and where you went wrong. By standing up and admitting your mixup, you will come out the other side stronger.

Related: How can we keep cloud architectures simple

2. Admitting you might be wrong

This can be harder. As engineers we like to problem solve. We spend years exploring math & science, looking for the “truth”. The more one searches for it thought, sometimes the more illusive it can be.

Measurements are never exact. And theories and architectures often fail in the face of real world traffic. Applications fail. Servers fail. Outages happen. Customers especially paying ones will inevitably get angry, and this can backfire onto you.

Be prepared for the real world. It gets messy.

Also: What hidden things does a deposit reveal?

3. Allowing space for others to be wrong

This is a tricky one. You may know what others don’t, but it may take finesse to share that truth. You may have to sell your perspective, even while another perspective may be measurably wrong.

Be prepared to sometimes let things break a little. As hard as this is, it may allow for others to learn.

Like immunizing, sometimes failure can teach what words cannot.

Read: Can communication mixups sour an engagement?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

How can communication mixups sour an enagement?

via GIPHY

I recently had some communications mixups with a customer. It reminded me how delicate, communications are between customers & vendors. What’s more they can be challenging between developers & managers. It highlighted for me these challenges, and the strategies I’ve learned over the years.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

While I didn’t lose the project, the initial misunderstandings continued to eclipse the project, long after they were cleared up.

1. First a missed conference call

Early on, we setup a call to discuss the challenges. The time of the conference call had been agreed to, but somehow it didn’t make it into my calendar. So when the appointed day & time came, i missed the call. This was before any contract was signed, or even the engagement had gotten started.

Needless to say this is a very delicate moment, as everything we do sets precedents about our personality and working style.

While we were able to reschedule, it added some initial strain to the relationship. As you’ll see that compounded more later.

Related: Walking the delicate balance of transparency

2. Next arriving late to the kickoff meeting

I always pride myself on timeliness. I think it communicates all sorts of things to customers. First it shows you’re serious and will manage the project carefully. Next it shows you respect for others time.

As usual, I left plenty of extra time, so I would arrive well before the meeting. Arriving at the building 20 minutes early, I searched but could not find the entrance. Neither could google as it turns out. Strange I thought, what could be wrong? I walked into the building where the address should be, and asked the doorman. He explained that the company didn’t reside there. Perhaps they’re not located at Park Avenue, but rather Park Avenue South, he suggested. And then the lightbulb goes off. Of course!

Realizing I now have 5 minutes to arrive on time, I’m going to be late. So I attempt to call the manager leading the meeting. I get his voicemail, and leave a message. I then jump in a taxi, and head to the Park Avenue South address. Arriving 10 minutes late, I quickly head upstairs. I’m greeted by some grumbling, and frustrated looks.

Despite this being an understandable mistake, it comes on the heels of another mixup. So now I’ve set a precedent of lateness. Despite being a timely person, it’s hard to erase the stamp that is there now.

We continued to have strained relations through the engagement. While it did finish to completion, I believe it would have gotten extended were I not to have stumbled early on.

Also: When you have to take the fall

3. What can a mixup indicate?

There are many questions it may raise. Possible ones include:

o Is candidate too busy with other tasks?
o Is the person forgetful?
o Is one party bullying on their perspective?
o Is there finger pointing & blame game in the org?
o What is the culture of the organization?
o Is it one of understanding & working together or blame game?
o Is the person uninterested?
o Is the project not a priority?
o Is the company disorganized
o Is miscommunication endemic?

Some of these thoughts may bubble up consciously, and some may linger as a bad taste in your mouth. Regardless, they should be faced head on, with understanding and humility on both sides.

Read: Why i ask for a deposit

4. The weight of first impressions

Inevitably, when there is a mixup, of lateness or missed meeting, there is a technical explanation. In my story above, the *reason* is Park Avenue and Park Avenue South are completely different addresses.

o First impressions are KEY

Even with a reasonable explanation, there is a reaction that is felt.

o There is a visceral emotional reaction we all have anyway

Such a reaction is easy to cause, but hard to patch up. It will take time, and multiple interactions to set a new impression to people.

o Reactions can be incorrect & irrational sometimes
o They can color further interactions

With time impressions can be adjusted, but it takes much more work after an initial mistake.

Check out: How to hire a developer that doesn’t suck

5. Possible solutions

While there is no sure fire way to avoid mixups like these, there are some things that can work in your favor.

o maintain flexibility

That means accepting blame, and mutual responsibility in reaching the goal posts.

o maintain a sense of I *can* be wrong

Everyone can be wrong, and everyone makes mistakes. So don’t try to avoid blame. That said emphasize that everyone must work together. On communicating engagement details, on mutual agreed times, and time zones.

o look for a sense of we *can* be wrong

I think these types of mixups can also be beneficial. For they underscore the customers management style. Do they point fingers, or acknowledge reasonable mistakes. Both parties will make mistakes eventually, and understanding of this builds good faith down the road.

o “let’s work together to improve communication”

Framing the mixup as a shared problem is important. Although the address mixup above is technically my fault, it’s probably a common one. Park Avenue South confuses everyone in New York. So an understanding customer might offer to share a bit in this with you.

o hold frame of mutual responsibility and working together using the word “we”

The frame is key. It’s not *all* your fault, nor is it the customers if they mixup. We all need to be understanding, to a point.

Also: Can daily notes help you work better with clients?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

What hidden things does a deposit reveal?

via GIPHY

I like this idea of how integration tests in software development show you that everything is working and connected together properly.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

I think it’s interesting to consider how a deposit may serve a similar function across the financial space & contractual space.

1. Alignment across business units

In really small organizations, everyone is in tight communication. Finance knows what engineering is doing. In medium to large organizations, there can be a disconnect. Engineering may be 100% ready to start today, but finance is not ready. In some cases finance may not even know a consultant is being hired. Each case is different.

Some CTOs get this right away, and are already ahead of the request. While others might ask, “Well we’re ready to get going today, do you really need the deposit first? Because that might take some time.”

My thinking is, yes the engineering department is ready, but the organization is *not* completely ready. And it’s better that there be alignment across the organization. Ironing out that alignment, helps avoid other problems later on.

Related: When you have to take the fall

2. Organization or disorganization

Sometimes there is complete alignment, the contract is already ready, and the whole org really is ready to go. In other cases there can be some disfunction. For instance the lawyers have a lot of hoops that want us to jump through, in terms of a contract.

In other cases finance may only cut checks on a certain day of the month, or only pay 30 days after receiving an invoice. There are a lot of different policies. By insisting that we receive a deposit, however small, we iron out these things early.

If the engineering manager or CTO hiring you promises one thing, but finance has a policy against that, you’ll want to know early to avoid misunderstandings.

Related: Why generalists are better at scaling the web

3. Trust

The amount of a deposit is really irrelevant. It’s all about getting ducks in a row. Both in terms of what may be required of you the vendor, and what the company’s policies may be when onboarding consultants.

By ironing out these issues early, the customer is showing some faith in you as a vendor. They want you in particular, and will do what they need to, to make it work.

Related: Is AGILE right for fixing performance issues?

4. We want you to rush, but we don’t

I’ve encountered many cases where engineering was “ready” but finance was not. It’s tough. From the perspective of the CTO it may be a moot point to get stuck on.

My thought is to hold the frame of two organizations working together. When the organization has alignment that hiring this engineering resource is a priority, it will get things done that it needs to.

Related: How to hire a developer that doesn’t suck

5. Stress tests or organizational integration tests

In software testing, we have something called an integration test. It might be confirming that a login works, or a certain page can load. Behind the scenes that test requires the database to be running, the queuing system to work, an API call to return successfully, and so on. A lot of moving parts all have to be working for that test to succeed.

In a very real way, a deposit is the financial equivalent of an integration test. It confirms that we’re all aligned in the ways we need to, and are ready to get started.

Related: How do I migrate my skills to the cloud?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Walking the delicate balance of transparency

via GIPHY

I’ve written before about How I use progress reports to stay on track.

Join 38,000 others and follow Sean Hull on twitter @hullsean.

I think it’s an interesting topic, and an important one.

While I do believe transparency is important when working with clients, that doesn’t mean it’s easy.

1. I start with daily notes

As I mentioned above I think they’re important. They provide visibility, improve trust, and keep me on track. They also help me remember what was happening on particular days. They’re like breadcrumbs on the path to building solutions.

Related: How to hire a developer that doesn’t suck

2. Notes can highlight organizational dysfunction

Often in my notes, there are details of who I coordinate to get what done. Perhaps I need credentials to reach a particular server. But to get those, I need an email address. And to get that, someone in department X must set that up. And there are delays with that process.

Those delays can cascade through the onboarding process, frustrating everyone. Although the operations team is read and raring to go, the finance or legal team is not quite ready, and there are delays there. Or there are hiccups in some other frequent business process.

Related: Why generalists are better at scaling the web

3. Notes can highlight task complexity

Sometimes I hear the phrase “That should be simple to do”. Only to find the devil buried in the details. As we put boots on the ground, we find there are many dependent tasks that are not finished. So those must be completed first.

In this case I think complexity of notes is a real triumph. For CTOs that are more management oriented, they may not have day-to-day understanding of coding complexity. And that’s ok. But when that complexity is laid out in all it’s gory detail it can be a real educational experience.

Related: How do I migrate my skills to the cloud?

4. For some CTOs high level is better

For some CTOs, they don’t want to slog through endless notes about setting up credentials, or problems with permissions of keys on server X or Y.

While in these cases I still collect the detail, I may also add some high level bullet points, that focus on what all these underlying parts are in service of.

Related: When you have to take the fall

5. Be prepared for archeological surprises

Inevitably there will be surprises. Whether department X does not know what department Y is doing. Or whether setting up an aws account takes two days, instead of two hours. Be prepared.

Inevitably I find these all help communication. And since I’ve been keeping them, I’ve never had a customer balk at an invoice. Notes don’t lie!

Related: Why i ask for a deposit

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters