What problem is DevSecOps solving? Was DevOps not secure already? In this video, I go over my understanding of what DevSecOps is and use container security as an example.
Hiring people with the right software skills is hard – for all of us! But it shouldn’t be as big of a problem as we make it out to be. Maybe there’s another way to “find” the right people…
Beyond, you know, not working, there’re good reasons to take vacation. Your brain will function better, your quality of work will be better, and all that digital transformation stuff will go better if you’re not running at full capacity. Management can do a lot to encourage people to take vacation and get charged up for work. In this episode, I got over three reasons why you should take vacation and three ways executives can make sure you do.
- You need to be limber for crisis time – organizations are killed by when things go wrong, so you need to focus on the “black swans.” De-stressing is good for this. Save up your stress budget for avoiding destruction.
- Vacation is part of your comp. don’t let your employer cheat you, rather, don’t cheat yourself!
- Always focus on the system, and then yourself – if you feel inadequate, it’s likely a system fault. You can focus on fixing that. But, you shouldn’t let it make you think you need to prove your worth.
First, you need people who are relaxed and well functioning. They can’t be stressed. I mean, I don’t know what else to tell you here.
- Executives need to lead by example – take time off; proactively tell staff to take a day off.
- Give more days off to show your commitment.
- Schedule work around holidays – Thanksgiving and Christmas code complete and GA dates are dumb.
Many people use “regulations” and “compliance” as an excuse to avoid changing how they build and run software. But, what if compliance was actually a beneficial feature, and auditors were “customers” you were looking to please? “Nobody thinks of it as ‘governance’ if it benefits them. They only call it ‘governance’ or ‘regulation’ if they don’t want to do it.” Let’s see if we can turn this frown upside down.
- Book office hours.
- Find out more about VMware Tanzu, including our kubernetes distro.
- Pivotal Cloud Foundry – the Auditor’s Guide.
- US Air Force story.
00:00 – People don’t like governance and regulations, but everyone has it.
00:49 – The three types of apps being governed.
02:27 – Enterprise architecture governance – governing decades of app design sprawl.
04:26 – regulations, like, laws and stuff.
06:54 – Treat regulations as a valuable feature, auditors as “customers. ”
07:39 – Example: we benefit a lot from banking regulations.
08:31 – Auditors are “customers” as well
10:50 – “Governance” is stuff you don’t want to do – so, hack your mindset.
11:20 – Auditing is an overly manual, error prone process – it needs better tools!
12:00 – Use automation and cloud native stuff to make auditing better
14:23 – Example: the US Air Force automates governance.
16:28 – Benefits of embracing regulations as a feature.
17:48 – Regulations are a strategic asset.
18:25 – Example: startup banks vs. big banks.
21:43 – Embrace regulation and compliance – good customer experience, done efficiently.
25:18 – The Return of Banana Boy.
20201207 Tanzu Talk – culture talk
Creating an innovation-driven culture is difficult and requires deliberate and well managed change to how you operate. Scaling it to a large organization is even harder. You also need the organizational context and norms – the culture – that allows innovate practices and thinking to thrive. Nailing these down, let alone what “culture” even is, can be hard. This talk will define what an innovative culture is and then cover several proven methods for leading culture change. Throughout, we’ll draw from use cases from large organizations that have tackled the challenge of changing to a innovation-driven culture.
- Find out more about VMware Tanzu, including our kubernetes distro.
00:00 – Intro.
00:50 – Origin of the culture talk.
01:32 – Slides overview.
02:32 – The Reward – European baking differences.
03:28 – Start of actual talk – agenda.
05:11 – How to draw an owl.
06:10 – My bio.
06:47 – Possible special guests.
07:17 – What’s driving all this? Why care to change?
08:52 – No one actually wants to change.
10:28 – Software failure is still very common.
12:52 – Daimler example.
16:04 – But, what is “culture”?
17:40 – More detailed definitions of “culture.”
18:08 – Culture: how we do things around here.
19:08 – The team’s innovation culture tools – innovation, risk takers, people-centric.
20:51 – The Home Depot example.
23:40 – What management gives the teams.
25:22 – Kitchen example.
28:12 – Leadership changes.
31:09 – Managers must kick-off blameless postmortems.
32:10 – Scaling culture changes, esp. in large organization.
32:29 – Make vision a tool, not (just) a statement.
34:29 – Start small and seed teams.
37:24 – People can change.
40:01 – Culture metrics – measuring culture change.
48:27 – Thanks! …and further reading.
43:28 – Consulting, internal marketing, branding, conferences.
48:57 – Common Q&A questions.
49:21 – End of presentation.
50:01 – CTA! Book office hours, learn about Tanzu.
51:53 – The Return of Banana Boy.
Last week I did a three part series on metrics for ALL THE DIGITALZ. Metrics are like anything else: people say your metrics are terrible if they don’t like them, but they tend to like their metrics.
Ultimately, if you’re changing how a large organization works, you have to “manage by metrics.” You also need to manage by “talking to people and thinking for yourself.” I mean, if you’re transforming a large organization YOU NEED EVERY THING THAT’S HELPFUL THAT YOU CAN GET YOUR HANDS ON.
Here’s the three types of metrics I went over.
Are we achieving the non-IT goals we’re here for? How would we know?
They’re metrics like:
- sales/workflow completion
- cost per transaction
- customer experience and satisfaction
For an indirect tracker, some people at TD Ameritrade come up with a way to track business value progress, i.e., “are we progressing at improving things?” by using # of apps deployed on the new cloud native platform (Tanzu Application Service, but you could use “kubernetes”) in dev and then prod. Their reasoning is good:
Traditional development and ops metrics.
- deployment frequency
- lead time for changes
- time to restore service
- change failure rate
There are mostly from the DevOps reports and little bit of SRE. There’s more SRE “golden metrics” that are interesting to contemplate. And the thinking behind “negotiating” error budgets between dev and ops (SRE) is probably a helpful way to think about SLAs (yes, yes – I know – DO NOT EMAIL ME).
How do you measure the state of your organization, the people in it and how they’re operating – “culture.”
These are much more squishy, but you can start with:
- Employee NPS (eNPS)
- Staff belief in leaders, mission, and strategy (do they understand strategy enough to do the right thing?)
- Staff retention and churn rate
There’s some interesting metrics commentary/survey work in a recent VMware sponsored survey:
If you prefer, all of this is written up in a guest column, but in a more serious, no-jokes way and with much less of my face. They’re also written up extensively in my books The Business Bottleneck and Monolithic Transformation.
Measuring your progress in transforming how your organization functions and runs – the “culture.”
Today, I go over five business metrics to track: (1) sales/workflow completion; (2) adoption; (3) awareness; (4) cost per transaction; (5) customer experience and satisfaction. There are, of course, all sorts of other metrics, but these are some you can start with as you figure out which metrics are the best for you. Check out the article I pull this from, and read even more in The Business Bottleneck.
If you’d like to start, book some free office hours with us.
When you’re managing your organizational transformation, it’s too easy to forget that you, too, must change. In today’s episode, I cover five things to check on. Rather, I watch myself covering those things. There’s some extra commentary, of course.
Download The Business Bottleneck for free.
When you’re looking to change how you do business with software, you better understand how software works. Coté shares a couple ways to come up to speed and an example. It’s another selection from his book, The Business Bottleneck.
A healthy sense of urgency – paranoia, even! – is what organizations need to keep evolving, and change in the first place. If you don’t like the negativity of that idea, you could think of it as curiosity. In this episode, I goes over the relevant section in his book, The Business Bottleneck.
All those fresh CI builds end up taking up a lot of bandwidth: someone has to pay for it! Paul joins me again to talk about the rising trend in open source projects that need to find container download patrons. In doing so, we also discuss Helm briefly. Also, we discuss some new ideas for Tanzu TV formats.
When should customize open source? As Coté says in this episode, if you have to ask, the answer is no. Rick Clark and he discuss strategic considerations for going beyond just using and embedding open source software.
Also, check out the panel that I mention planning for in the beginning.
Coté goes through his opening talk for “round tables” and “fireside” chats. Also, he answers the age old work-form-home question: are cucumbers good enough to transform seven month olds into good office mates?
In this episode, Coté is joined by Rick Clark and Sophie Seiwald to discuss management challenges of remote working. You know the drill: everyone has been working from home since the spring, taking away all the advantages and habits of working face-to-face. What’s new in this conversation is some advice for doing strategy communication, something that’s especially important when you’re relying on autonomous developer teams. We also discuss keeping people’s spirits up and making casual conversations with the boss more like running into each other in the hallway instead of an ominous “we need to talk” meeting.
You don’t have to make an A on everything, try for more B’s and C’s, even F’s. Doing perfect on every project is a path to failure, if not misery. So, why not be OK doing less than perfect on some projects, and completely failing on others? This is howI’m getting gets comfortable saying “no” more often, which so far has worked out.
When it comes to digital transformation, kubernetes, and app development, executives are always stressed about skills gaps. They don’t think staff people are up to the tasks and they don’t have the budget to hire new people with that occult knowledge. However, this might be more about the lack of training and strategic learning methods in those organizations. What if the problem wasn’t a lack of skills, but a lack of learning? In this episode, Coté goes an analyst report that looks at this situation and walks through some tactics to address the (supposed) skills gap.
00:00 – Skills gaps.
00:40 – Survey says: people worry about skills.
05:37 – The types of skills that are missing.
09:19 – Three ways to get the skills your org. needs.
16:31 – Learning how you learn – don’t forget to measure.
17:14 – CTA – http://kube.academy, http://tanzu.vmware.com/developer
19:23 – Bonus: get free training from deal-hungry ‘vendors.
Doing test-driven development is the best way to maintain software release speed and avoid “legacy” software slowing you down. Coté lays out what TDD is, why it helps you avoid legacy slow-downs, and shows that most people don’t actually do it.
As with other episodes this week, this one builds on one of the ideas in the book Radically Collaborative Patterns for Software Makers, which you can get for free – check out the links in the episode or the link at the end of the episode.
- Test-driven development
- State of Agile surveys.
- The Necronomicon
- Avengers time travel theory.
- Eternal return.
Most development teams forget to do a key activity: measuring the success of new features. Teams need to create metrics that will validate or invalidate the assumptions behind the feature and also alternate implementations. But it starts with creating measurements!
In this episode, I discuss the importance of measuring your software, some types of measurements, and an example of measurements in action at The Home Depot. As with other episodes this week, this one builds on one of the ideas in the book Radically Collaborative Patterns for Software Makers, which you can get for free – check out the links in the episode or the link at the end of the episode.
- Don’t forget to measure things.
- You often assume someone else will be measuring.
- This means you can’t use it as feedback – only focus on project metrics (budget, schedule, QA, delivered features) for feedback – plus negative bug reports!
- Some starter metrics:
- Awareness – do people even use your new feature?
- Completion rate – buying a thing, signing up for an account, going all the way through a workflow.
- Time spend on workflow.
- Accuracy – generic, but whatever.
- Churn rate/retention; lowering operating costs; growth; doing loose-causation activities (loyalty programs, educating self on banking activities).
- Loose example: Home Depot buying washing machines (shows that you need to focus on end outcome, not just app itself).