David Pratten is passionate about leading IT-related change projects for social good. 1810 stories · 0 followers

## Leading Change from Deep in the Org Chartby Mark Schwartz Sunday June 24th, 2018 at 5:58 AM

1 Share

In earlier posts in this series, I talked about the challenges and techniques of driving change from a senior position in the organizational chart (Driving Change from the Top Down: Wielding Organizational Powerand Top-Down Transformation: Shu-Ha-Ri to Go Beyond Command-and-Control) and from a middle management position (Transforming Up and Down: Leading Change from the Middleand Leading from the Middle Part Two: Selling Ideas and Playing Politics).

This post is dedicated to change agents who are at the implementation level: executors—you know, the people who actually get things done! While many of the readers of this blog are CXOs and senior leaders, I’m hoping these ideas will help them spot people in their enterprises who are struggling to promote new ideas. And if you happen to be an implementor in an enterprise that has multiple layers of management and something of a hierarchical culture, then these suggestions may give you some ideas to work with.

Let’s consider the advantages and disadvantages of driving change from this position. On the plus side, you can actually implement changes yourself, which many in management cannot do. You are also responsible for the quality of your own work and your productivity, so in many cases you are free to make changes that demonstrably improve one or both of those things. On the minus side, you do not have direct control, or even much influence, over most of the organization, so scaling your changes is harder. You need to ask permission for many of the things you do, especially if they require money or go against current policies. So…let’s find ways to leverage those pluses and overcome the minuses.

The first principle is to start small. One of the leadership tricks that I have learned is to have a big vision—know where you are trying to go—but actually execute small, moving incrementally toward that vision. What is the smallest and quickest thing that you can do that will move the enterprise toward whatever you are passionate about changing? It will often be something that you can do without asking permission. So instead of fighting the bureaucracy by advocating for a major change—a transformation, which is a perceived risk to the enterprise—I would start small.

For example, if you are a software developer trying to move your organization toward DevOps, maybe the place to start is by writing automated tests for your own code using best practices for testing. We both know that if you do this right, it will reduce your development time and increase the quality of your work—so, probably, no one will object. Next add automated builds. Then perhaps change your branching structure. Then implement continuous integration. If tools are not available, see if you can use open source tools so that you don’t need a budget. Keep going until you hit an unmovable impediment.

The next step is to take advantage of the relationships you have built, particularly with your close teammates. To continue the DevOps example, perhaps you know a sys admin who likes to script changes. Perhaps you can get him or her to collaborate on writing deployment scripts. Or perhaps the team will agree to a better branching strategy and continuous integration. Again, continue until an immovable obstacle appears.

Now we must cross the chasm into selling ideas upward in the organization. The key is to figure out the next increment of change and what you need to get there. To sell it, keep two things in mind. You need to show a concrete benefit (if possible, through working examples) and you need to minimize risk for the manager. When I say a concrete benefit, I mean notsomething like “DevOps is a best practice” or “everyone else is using DevOps” (though these points do have some use—see below). Instead, something like this is more likely to work: “Hey, manager. You know how we keep taking down the system every time we do a deployment? Well, I measured and found that 60% of our deployments cause problems. But I think I can fix that. Companies using continuous deployment usually average less than 1%. Let me show you this working CD prototype.”

This positions the new idea as something that solves a real problem or adds a measurable benefit. But it is still necessary to minimize risk. The working prototype is a good risk mitigator, but it’s a good idea to imagine every “what if” that the manager might bring up. I say that as a very experienced manager full of “what ifs”.

Your case will be strengthened considerably if you can make it clear that you have invested personal time and effort and will continue to do so. It also reduces risk, as management will know that someone will continue driving the effort and taking on the challenges.

Let’s assume that you have had some success in your corner of the enterprise. Now it’s time to scale it across the enterprise. Eventually this might require selling ideas to senior leadership, but there are a few other paths to pursue first. In order to get a grassroots movement going, you might be able to create a “birds of a feather” group internally, set up brown bag lunches, or pair with others who are interested in your topic, thereby improving your practices. You can also attend meet-ups outside the enterprise to see how others have managed their transformations.

If you are able to get something of a movement going, you might then look at bringing in experts. Perhaps you can invite people with expertise to come speak or lead discussions. You might be able to seed the environment with books or get people to attend lectures from thought leaders. Now is the time to bring in ideas about “what everyone else is doing” or “what best practices are” in order to strengthen your case. What you’re doing is planting seeds and gently changing culture and established ways of thinking.

Finally, it will be time to take the ideas to senior leaders. It might not be necessary, but I have found that changes tend to ripple out only very slowly until you get that senior leader on board. You can introduce DevOps practices, for example, but if the enterprise doesn’t change how it chooses investments, plans initiatives, and measures success, then those DevOps practices will not lead to the business results you hope for.

Hopefully by this point you will have built grassroots support and support through a number of layers of management. When they arrive at this stage, many people think they should put together a business case that shows how the new initiative will have a good return on investment (ROI). While this is not necessarily a terrible idea, I would suggest that in many cases it is the wrong strategy. Any ROI justification case will have lots of assumptions, and senior leadership are experts at picking those assumptions apart. The ROI case is likely to seem too abstract on the one hand, or too detailed on the other.

Instead, I think it works best to focus on concrete pain points or objectives and show how your new ideas will address them. An ideal conversation would sound something like this: “Hey, big boss. I wanted to ask you to support a new initiative that we already have underway. I know that you sometimes think our IT approach doesn’t allow us to respond quickly enough to new business needs. Well, this technique we’re using seems to be helping with that. For example, in the BobbleHeadFeature case, we were able to deliver new bobbling patterns in just two weeks. Mr. Toymaker is really excited about it. We already have 20 teams using this new approach, and it seems to be working well. The thing is, we’re hitting a roadblock. What we really need from you is…”

If you can put a conversation like this together, then you have mastered the art of managing change upward through an organization. Congratulations! Let me know how it goes so that we can share your success stories with others in the same position!

drpratten
10 hours ago
Sydney, Australia

## Leading from all Levels: An Ebook of Change Leadership Practicesby Mark Schwartz Sunday June 24th, 2018 at 5:56 AM

1 Share

Transformations can be driven from all parts of an organization. What’s essential is passion, commitment, vision, and a willingness to take on challenges. Driving a substantial transformation in an established enterprise is difficult whether the change agent is in a senior role, somewhere in middle management, or a hands-on implementor: a software developer, infrastructure engineer, or IT operations specialist.

When our enterprise strategy team speaks to enterprise customers, we often remind them of the importance of having an executive sponsor for their transformation efforts. And it’s true—executive sponsorship is an important lever for shifting the organization in the direction of its transformed state. But many of the companies I talk to rightly point out that they just don’t have that support from the top, and I would never suggest just waiting until executive support magically appears!

On the contrary, I think there are viable strategies for driving enterprise transformation from every level of the enterprise, and I have seen many of them succeed. I speak regularly at IT Revolution’s DevOps Enterprise Summit conferences, where the audience is consistently amazed at the stories told by change agents from all levels and roles and in virtually all industries. Leading transformation is first about passion and second about finding ways to get the enterprise to change.

And by the way, leading a transformation from a senior level also has its challenges, as I discovered when trying to do so at US Citizenship and Immigration Services.

I wrote this series of posts in the hope that it would help change agents, wherever they may be on their enterprise’s org chart.

In the first two posts of the series, I talked about driving change from the “top”—from a senior enough position to be able to control or influence virtually all the resources necessary for the change. This might be a CIO, CDO, or CTO position; a senior IT leadership position; or really any CXO position. The challenge in this case is the organizational distance between the change agent and the implementors of the transformation, and the need to convert command-and-control power into the more agile kind of servant leadership that works best in a digital enterprise. The two posts were:

My next two posts looked at transformation from the point of view of middle management; that is, change agents who find themselves with control and influence over some parts of the transformation but also need to gain support from those more senior to them organizationally. In this case, the change agent needs to “sell” ideas up the org chart while simultaneously motivating those “down” the org chart. This requires managers to confront those tasks that are anathema to technologists and technical managers: selling and playing politics. I try to show that these tasks are not as painful or disturbing as they might sound. Take a look at these posts:

But change agents who are implementors, individual contributors, or technologists—that is, with limited scope of influence—should not feel discouraged. They have the advantage that they can cause change in a hands-on way (as opposed to CIOs like me, who don’t actually doanything), and can follow strategies that make it easier to sell upward in the organization by mitigating risks before they become a concern. I talk about “leading from the bottom” in this post:

I hope that these ideas are useful to all change agents, because it is important that we all support those who have the passion and energy to drive transformation. Most of all, I hope that everyone will feel encouraged—transformation is hard but possible. I should know—I spent years working to bring transformation to the federal government.

drpratten
10 hours ago
Sydney, Australia

## I don't want to lose what I've gotby John Goodpasture (noreply@blogger.com) Sunday June 24th, 2018 at 5:54 AM

1 Share
Don't want to slip backward, take a demotion, less pay, risk your savings? Same answer if there is a prospect of doing a whole lot better if you'll just take a risk ...? Prospect theory may be for you! Daniel Kahneman and Amos Tversky may be a project manager's best friends when it comes to understanding decision making under conditions of risk.  Of course, they've written a lot good stuff
drpratten
10 hours ago
Sydney, Australia

## The Multiverse Falsifiedby woit Tuesday June 19th, 2018 at 2:51 PM

1 Share

The July 1 issue of the Monthly Notices of the Royal Astronomy Society includes an article evaluating the standard multiverse prediction of the cosmological constant, with result:

The predicted (median) value is 50–60 times larger than the observed value. The probability of observing a value as small as our cosmological constant Λ0 is ∼2 per cent.

If your theory only makes one prediction, and that prediction is off by a factor of 50, that’s the end of it for your theory. I’m very glad that this has now been sorted out, the multiverse hypothesis has been falsified, and theorists who have been working on this can move on to more fruitful topics.

drpratten
5 days ago
Sydney, Australia

## Four Is Not Enoughby Patrick Honner Tuesday June 19th, 2018 at 2:00 AM

1 Share

Suppose you want to cover a standard 8-by-8 chessboard entirely with rectangular dominoes that each cover two squares on the board. It’s easy to imagine how you might do it: You could line the dominoes up horizontally, four in a row, or vertically, four in a column. You could arrange them like stairs, concentric squares or gnashing teeth. There are nearly 13 million ways to do it, and each arrangement requires exactly 32 dominoes, since the total area of the chessboard is 64 squares and each domino covers 2 squares.

But what happens if we remove a pair of opposite corners from the chessboard? How many ways can you cover this new board with 2-by-1 dominoes? Those unfamiliar with this classic problem may be surprised to learn that the answer is zero. It is impossible to cover this altered chessboard with 2-by-1 dominoes. How did we go from 13 million to zero so quickly? The answer is remarkably easy to find, if you know where to look.

The squares on a chessboard alternate in color, between dark and light. This has two important consequences for a standard 8-by-8 chessboard: First, there must be an equal number of dark and light squares, and second, opposing corners must be the same color. This means that when we remove a pair of opposite corners, the number of light squares that remain will be unequal to the number of dark squares. But every 2-by-1 domino must cover one dark square and one light square, which means a collection of dominos can only cover a chessboard with an equal number of dark and light squares. Our altered chessboard cannot be covered.

Of the many wonderful chessboard math problems, this one is my favorite because of its surprising solution. Who would expect the coloring of the squares to be the key to unlocking the puzzle? But mathematicians have been using colorings like this — which indicate structure and imply categorizations — to solve problems for a long time. And a recent advance in plane coloring has breathed new life into a problem that has stumped the mathematical community for over 60 years.

Consider the standard geometric plane, an infinite expanse of points in two dimensions. Your task is to color each of the infinitely many points in the plane. You might wish to color the entire plane red, or maybe half red and half blue, or maybe you’d splatter the color like in a Jackson Pollack painting. But there’s one rule in our plane coloring problem: If two points are exactly 1 unit apart, they cannot be the same color. Can you color every point in the plane without violating this rule?

“Of course!” you might say, “I’ll just use infinitely many colors.” There is a certain elegance to this sneaky approach (setting aside the philosophical question of whether infinitely many colors exist), but can you do it with finitely many colors? And if so, how many different colors would you need? Finding the minimum number of colors needed is known as the Hadwiger-Nelson problem, and it’s also often described as finding the “chromatic number” of the plane. (The chromatic number is a property of graphs, which are collections of vertices, or nodes, and the edges, or lines, that connect them. The chromatic number of a graph is the minimum number of colors needed to color all the vertices so that no two vertices connected by an edge are the same color. This is related to an alternate formulation of our plane coloring problem involving so-called unit-distance graphs.) The Hadwiger-Nelson problem was first posed nearly 70 years ago, and we still don’t know the minimum number of colors we would need. But the new result has narrowed down the possibilities. So, what are the possible numbers?

First, let’s see that finitely many colors will do. This red square will help us see why.

The red square above has side length $latex \frac {2}{3}$. Suppose you have two points in this square: How far apart could they be? The maximum distance between any two points in a square is equal to the length of the square’s diagonal, which we can compute using the Pythagorean theorem.

$latex d^2=\frac {2}{3}^2+\frac {2}{3}^2$

$latex d^2=\frac {4}{9}+\frac {4}{9}$

$latex d^2=\frac {8}{9}$

$latex d=\sqrt{\frac {8}{9}}$

And since

$latex \sqrt{\frac {8}{9}}<\sqrt{\frac {9}{9}}=\sqrt{1}=1$,

we know that the distance between any pair of points in this square is less than 1 unit. This means that we can color this whole square red and not violate our plane coloring rule.

Now, let’s make a bigger square out of nine of these little squares of side length $latex \frac {2}{3}$, and we’ll give each one its own color.

Since each square has a different color, we still have not violated our rule. Of course, since this large square (made of nine smaller squares) has a side length of 2, we’ve only covered 4 square units of the plane. But we can get the rest by copying and pasting!

We can cover the entire plane like this, but have we satisfied our rule about using different colors for points 1 unit apart? Just think about the red squares. We’ve already shown that no two points inside any one red square are 1 unit apart. Now, since each little square has side length 2/3, the minimum distance between any two distinct red squares is $latex \frac {2}{3}$ + $latex \frac {2}{3}$ = $latex \frac {4}{3}$, which means that any two points inside two different red squares will be more than 1 unit apart. Thus, no two red points in the plane are exactly 1 unit apart. And since the same argument applies to all nine colors, this is indeed a valid coloring of the plane in which no two points of the same color are exactly 1 unit apart. This shows not only that the chromatic number of the plane is finite, but it is at most 9.

A slightly more complicated argument using regular hexagons shows that seven colors are actually enough. You can surround a regular hexagon with six others and give them all different colors.

As with the squares above, you can extend this coloring in every direction.

By making the hexagon the right size — a diameter of slightly less than 1 will do — and extending the pattern correctly, we can be sure that no two points exactly 1 unit apart will be the same color.

So we’ve established an upper bound of 7 on the chromatic number of the plane. Can we easily establish a lower bound?

Well, it’s easy to see that we need more than one color. Take a point, P, in the plane: P needs a color, so let’s color it blue.

Since the plane extends infinitely in every direction, we know we can find a point, Q, that is exactly 1 unit away from P.

Point Q needs a color too, but our rule says Q can’t be blue. So we need a second color. Let’s color Q red.

Thus, the chromatic number of the plane is at least 2. Are two colors enough? Since the plane extends infinitely in every direction, there are actually infinitely many points 1 unit away from P. In fact, this is the definition of the circle of radius one centered at P.

Since P is blue and every point on the circle is 1 unit away from P, no point on the circle can be blue. With only two colors, that would mean that every point on the circle would have to be red.

But now think about things from Q’s perspective: Nothing 1 unit from Q can be red. But, just as with P, there is an entire circle of points exactly 1 unit away from Q.

This new circle around Q intersects the red circle centered at P at two points: Let’s call them R and S. Points R and S can’t be blue, because they are 1 unit from P, and they can’t be red, because they are 1 unit from Q. So we need a third color. Let’s color R and S green.

Notice the familiar geometric shapes emerging here: PQR and PQS are both equilateral triangles, and PSQR is a rhombus. Some elementary geometry shows us that $latex SR = \sqrt{3}>1$ , so we know it’s OK to color both S and R green.

This demonstrates that the chromatic number of the plane is at least 3. A clever trick will get us to 4. Consider that rhombus we just made.

Suppose we have two copies of this rhombus sitting on top of each other. Imagine that we drive a nail through R, so that the two rhombuses hang like pictures on a wall. Now we grab the bottom vertices of the two rhombuses and slowly pull them apart.

The rhombuses stay rigid as we pull them apart, and all the colorings remain valid. That is, until we pull them far enough apart so that the two bottom vertices are exactly 1 unit apart.

Now we have a problem. The two bottom vertices can’t both be green, because they are exactly 1 unit apart. Nor can they be red or blue. We need a fourth color! This diagram is called the Moser spindle, named after Leo and William Moser, and it proves that the chromatic number of the plane is at least 4.

In summary, we now know that the chromatic number of the plane is at least 4 but at most 7. And for nearly 60 years, this was everything we knew about the problem. Until Aubrey de Grey announced the discovery of this mathematical object in April 2018.

Just as the Moser spindle creates intricate interdependencies among its seven points that cannot be satisfied using only three colors, the 1,581-point construction by de Grey shown above cannot be colored using only four colors without a pair of points 1 unit apart being colored the same. But unlike with the Moser spindle, it’s not easy to see this just by looking — in fact, it takes a computer search to verify that four colors really aren’t enough. Thanks to de Grey’s discovery, we now know that the chromatic number of the plane is at least 5. Combined with our previous knowledge, that means we know that the chromatic number of the plane is either 5, 6 or 7. We just don’t know which!

This surprising result from de Grey, a biologist and recreational mathematician, has re-energized the mathematical community around the problem of coloring the plane. A collaborative online effort quickly sprang up to verify de Grey’s graph and find simpler versions (there are now examples using only around 800 points), and mathematicians are exploring whether de Grey’s techniques might be extended to get the lower bound to six colors or even seven. But some mathematicians suspect that the true answer to the Hadwiger-Nelson problem is unknowable, and that the chromatic number of the plane depends on independent issues like how we allow ourselves to think about and choose from infinite sets of points.

Still, there’s no question that de Grey’s result has gotten mathematicians excited about this elementary open problem, and many believe that an answer may be near at hand. Will we find it? Color me optimistic.

Download the “Four Is Not Enough” PDF worksheet to share with students.

drpratten
5 days ago
Sydney, Australia

## Getting started with App Maker: a detailed walkthroughby Google Apps Developer Blog Editor (noreply@blogger.com) Monday June 18th, 2018 at 4:44 PM

1 Share

We recently made App Maker generally available. App Maker is a new, low-code development environment for G Suite that lets you build a wide range of apps for your business and customize processes to help you be more efficient.

Building apps in App Maker is easy. You can declaratively define your app’s backend data, visually design a UI, add custom behaviors with Code (optional) and publish your app quickly.

To get familiar, here’s a quick walkthrough of App Maker’s main app development features.

With App Maker, backend Data Models are created in a declarative manner so you don’t have to worry about writing a lot of database code. Supported App Maker Data Models include:
• Cloud SQL - connects to Google Cloud SQL (GCP account required).
• Calculated - a computed virtual model via Scripting or SQL. It can also connect to external data (JDBC, REST).
• Directory - fetches your organizational data.

To build Data Model Fields you can either build them from scratch, or use an existing CSV or via a Google Sheet.
After defining the structure of your Data Model you can insert validation rules to limit what data can be saved.
Building relations (one-to-many, many-to-many, etc.) between data models is easily doable in the App Maker Relation Editor.
The App Maker Model editor also provides a variety of other features that include setting up custom queries and filters, securing data access based on Roles as well as triggering Data Events based execution. See the Data Models documentation for more info.

App Maker helps you streamline UI development by providing a visual design environment where you can drag and drop UI elements (Widgets) onto a canvas and then set the properties of the widgets using a Property Editor. Or if you want, there are also helpful UI generation wizards that can create ready-made UI structures, including Edit or Insert Forms, Tables and a variety of Charts to further speed UI development.
The look and feel of the UI is governed by CSS, where the default is Google's Material design standard. A variety of style variants are available in the editor so that the author can easily toggle how a widget is rendered via a dropdown menu or direct CSS editing.

The UI is connected to backend data via App Maker’s data-binding feature which allows an author to connect widget properties to data model fields.

The combination of visual design, databinding, CSS UI Styling with, Google Material as a default, all contribute to a productive UI creation experience. For full coverage of App Maker UI concepts. see the UI documentation.

### Enrich your apps with code

Although App Maker does all the heavy lifting when it comes to database communications and UI design, sometimes you need to customize application behaviors. This is where App Maker’s scripting feature comes in.

The scripting language used by App Maker is JavaScript, which is used in both the Browser (Client) or Server. The Server’s runtime environment is Apps Script which provides access to a vast library of G Suite services for common operations with Gmail, Docs, Sheets, Calendar and other services.

App Maker streamlines the process of writing code by providing an intuitive Code Editor that’s equipped with helpful Code Completion.
Plus, App Maker provides syntax error highlighting along with an interactive warning/error indication feature. For more information on App Maker coding topics, see these Scripting Docs.

### Previewing and publishing your app

Finally, App Maker provides an easy-to-use Preview feature where you can quickly test your app on your own. When you’re ready to share your app with users, App Maker provides a comprehensive Publish (or Deployment) feature. To learn more about previewing and publishing apps, see the publishing guide.

### Try App Maker today

Now that you have a general idea of App Maker’s features, have a go at the App Maker Codelab. Note: You’ll need to have App Maker enabled on your domain via G Suite Business/Enterprise or G Suite for Education.