I've been a senior computer scientist for the government of Canada since 2018. Sometimes reality doesn't reflect the official messaging in government. So this page lists some of my own guidelines, truths, and tools that have most helped my career in government and guard my sanity. I hope this page is useful to anyone new in government, especially tech people who care about doing a good job.

Caveat: Government is huge and teams are different. I hope this generalizes well and I think it does, but my personal experiences make me biased.

Starting with the most important items:

Why Trumps What

The specifics of a rule are less important than the reasons why it exists.

Try to understand why a rule exists. You can bend or break the specifics of a rule so long as you follow the true reasons why it exists.

For example ask yourself "why" is this the deadline or "why" is there a deadline at all? Maybe someone made a promise to management and if they're not ready it will be embarassing. The "why" of the deadline may actually just be for that person to feel okay. Respecting the specifics of the deadline isn't necessarily the only way to accomplish that.

Be honest, thorough, and upfront about following the spirit of the rules and you can bend deadlines, simplify processes permanently, and skip "requirements".

See also Chesterton's Fence.

Social Media & Political Activities

Nobody cares unless your views are fringe or you're a manager+.

Officially public servants can have virtually no voice on social media, especially for political statements critical of the government. However in reality this only starts to matter based on these factors:

• are your views fringe or extreme?
• are you a manager+?
• are you using your real name?
• are you declaring these as public servant political opinions?
• might you be picked up by legacy news media?

Nobody cares about your social media - unless you answer yes to many of these.

I've been told a few times by the Values & Ethics (V&E) team that I cannot identify myself as a public servant on social media. I've replied that most of my colleagues, my manager, my director, DGs, and DM are all active on LinkedIn so I'm refusing to do what they say.

It's not the job of the V&E team to give reasonable practical advice to help public servants live their lives. Instead they interpret rules with extreme caution to protect the employer. They are only advisers and only your supervisor can tell you what to do.

Organization System

All serious professionals have some kind of organization system.

There's a personal organization system called Getting Things Done (GTD) that I've modified and used for many years. I won't go deep in this section about GTD but if you don't have any organization system you absolutely need one if you want to be a serious and trusted tech professional.

Some core concepts of GTD include:

• Don't clutter your brain tracking what needs to be done next.
• Keep checklists for weekly, monthly, tri-monthly, and yearly reviews.
• Reviews should not take long because you're not executing tasks during reviews. Instead you're getting organized and prioritizing.
• For every person and every team, keep a scratch space of things you should mention to them the next time you meet.
• For each ongoing project, regularly define the next tiny task to make progress on it.

And more. I also maintain and execute checklists for events like "new member of the team".

Deploy First, Justify Later

"You can't justify a bridge by the number of people swimming across a river."

Sometimes, the people who will benefit from a new project most may never understand the benefits until the benefits become real to them.

Several times now, I've recognized that it would take more time and effort to justify a project than simply deploying it. As a professional some of your work hours are appropriately assigned to developing your own ideas that you judge to be useful to your team. Take time to do what you think is best. Use the results to justify the project later. This works best with free and open source software (FOSS) and if you have the skills to deploy all by yourself.

Bizarro World Training

Most government training is not worth doing thoroughly.

Don't waste your time thoroughly completing mandatory government training. There's this whole bizarro world of government training which is totally separated from reality. It just gives people something to do or checks a box. See also "Training Spreadsheet".

In government you'll find a ton of working groups, communities of practice, meetings, discussions, design sessions, and presentations about a topic in government that have very low information density. You'll learn almost nothing. Instead, earn a certificate that a private citizen might pay for, or register for a university course, or read a book.

Professionals have a duty to spend their time wisely and not just blindly do as they're told. Spend your training time only doing the best training available. Skip or do the minimum to pass all other types of training. The reason "why" that training exists is not to help you do a better job. If you just help them check that box minimally, you fulfill the true reason "why".

Training Spreadsheet

Nobody is tracking your training history. Track it yourself to skip duplicate mandatory training.

There are many training divisions, departments, platforms, vendors, and accounts in government. It's a mess and nobody is responsibly curating your training history data as the years roll by.

I have a spreadsheet on my personal cloud drive called "Stuart Spence Training History" shared read-only with anyone who has the link. Currently it lists 79 government training courses I've completed with columns for name, code, completion date, and links to certificate files if any.

In government you will sometimes get random emails for some "mandatory training course". The content is generic and forgettable because the "why" for this training is not any measured training outcome (see "Bizarro World Training"). Did you already do this course? Not sure. Or was it just named similarly? Where was that certificate again?

Several times I've replied to these emails like this:

I see this course is called "Navigating Ethical Turtle Acquisition in Government". Well three years ago I completed "Turtle Acquisition Values & Ethics" however it had no course code. Here's the certificate. Have I already completed this course?

Often the answer is yes. I saved myself two hours and I can tell my supervisor I've met the requirements.

Monthly Summaries

Everyone feels like you did nothing this month until you write it down.

Most work days, I write a few words into a private spreadsheet describing what I did. Each row is a day.

Every month, I write those notes into a monthly summary. I review a checklist of things to help me remember my month. I look at my spreadsheet, project contributions, calendar, etc. The summary is short and doesn't take long to write.

Every month I share this with my supervisors. So it doesn't matter how busy or distracted a supervisor was - every month if they spend 30 seconds they get a pretty good idea of what I've been doing. This also makes it easy for them to write the PSPM yearly reviews. See also "Help Your Supervisor".

If you can access gcpedia, you can see my summary for every month since 2018. However the basic format is:

# January 2026

Here's what I did this month, starting with most time spent.

* Category/Project: (1-3 sentences with links)
* Category/Project: (1-3 sentences with links)
* Category/Project: (1-3 sentences with links)
...

This is your career and your data. Make sure it can be widely shared (gcpedia) and that you have a personal backup.

Assume You're Ghosted

Suppose you're ignored forever. What will you do about it and when?

Suppose you send an email or submit a ticket and now you're waiting on someone else. Maybe you have no working relationship with them yet and don't know how much you can trust them to followup. Maybe you know they won't followup. Maybe the ticket platform has a history of closing your tickets with no notifications.

Ask yourself: let's assume they never address this and you're ghosted forever. By what date do you need to take some action and what is that action?

Set a reminder to yourself to do that on that date. Now you should clear your mind of this and work on anything else.

See also "GTD".

Declare Their Approval

Put it in writing that if you hear nothing by some date, you assume you have their approval.

Suppose you need some kind of approval (like security, ethics, legal, AI assessment) from some team however they have few resources, or your project requires new kinds of processes or evaluations. You've been waiting for weeks or months, you've escalated, and this otherwise simple evaluation is going nowhere. Maybe you're even starting to get ghosted.

Next step: Write out the new process. Evaluate yourself. Write a nice PDF with a title, executive summary, author, date, and even pretty colors. Share it with the team with a note like "Here's a new draft process I propose and how I evaluated my project." Provide a date deadline for them to provide feedback, and write that you're assuming they're okay with all this if you get no response by that date. You get no response. Now you can move forward.

Yes, you're doing their job. Yes, you shouldn't have to. No, this isn't exactly an approval. But it's useful.

Be sure to CC many people.

Related quotation:

Seek forgiveness, not permission.

Identify Their Goals

If you think someone is incompetent or lazy, maybe they just don't share your goals.

I want to build software that's useful, simple, maintainable, robust, and automated. I also want to teach. I'm pretty transparent about this and I hope that transparency helps people work with me.

Not everyone shares these goals. Here are some examples based on real experiences:

• Upper management are pushing hard to sign a huge contract with expiring cloud credits when we don't even have the staff to use what we have now. Superficially this may seem incompetent. But their goal may be to sign the largest dollar amount contract that they can to advance their careers. So arguing that it's too expensive is a bad argument because they like that it's expensive. Argue instead that it will be embarassing when we waste all that money.
• Developers are over-engineering our projects. You might think they're inexperienced or don't know how to build simple things. But their goal may be to try out new and modern tools even if it makes no practical sense. Maybe it's for fun or maybe for Resume Driven Development (RDD). So arguing that a component is overkill is a bad argument because they want to explore that overkill. Argue instead that it's bad for your career to bloat a project until it dies. Delivering software that's useful for years is the best thing to put on a resume.

Criticize Processes, Not People

Identify bad processes - don't blame people for being stuck using bad processes. Offer to help people with their work - don't blame them for not having the resources to help.

You blame someone today and someone else will blame you tomorrow. You'll be stuck in a toxic mess. Instead try to get everyone to agree that the current processes could be better.

Conway's Law

There are many laws, theories, principles, and patterns for developers and I recommend becoming eventually familiar with most of them. One of the most relevant to government is Conway's Law:

Software architecture mirrors the org chart.

Government of Canada silos are strong. It's an important skill to recognize when immense software complexity was not designed intelligently with purpose. It's just a result of Conway's Law. If you want to improve this kind of software, you also need to think about the org chart and include non-technical strategies like building human connections with teams.

Serenity Prayer

"Grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference."

Example: The employer provided headset hurts your ears and has bad audio quality.

The mandated headset choices are terrible but you (likely) have no power to fix that problem and need to accept that. Have the wisdom to buy your own excellent headset with your own funds. Yes it's not technically a thing you must do. But you use this equipment everyday and your life will be much better. Have the courage to announce this in conversations: "the employer doesn't provide me with the equipment to do my job".

Maybe your courage does have the power to fix this some day. But today, you have a comfortable headset and your voice sounds more professional in all your meetings.

Help Your Supervisor

Help your supervisors. They have more to do than solve your problems.

• Ask them what is hardest about their role and how you can help. You'll learn what's most important and may be given higher level work.
• Write summaries (see "Monthly Summaries") so they don't need to work to understand what you're doing.
• Thinking up solutions to problems is work. If you can, do that work so they don't have to. You only ask them to make a choice.

It's natural that you're a time sink for your supervisor when you start a new role. But try to be useful and save them time as soon as you can.

Say No

It's an extremely important skill in life not to do things for people just because they told you to.

For the past few years I've let my supervisors know that I like to spend 10% of my time teaching or making training materials. This has always been well received. Sometimes this puts me in contact with training teams who like what I've made. Sometimes training managers want to steer my enthusiasm and efforts into their own projects which are stalled. Or sometimes they're assertive about how I should change my format or style or follow their standards. They're not my boss. Just because they ordered me to do it doesn't mean I have to.

If someone confidently tells you to do something that doesn't mean you must do it.

Closing Thoughts

I hope this was useful. Do you think anything could be added to this page? Let me know.

Best of luck!